From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A5B1D20248 for ; Wed, 17 Apr 2019 19:44:55 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:cc:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=M1QUHJktNrZPhKdL QI7hefmDGAgmwqdBlEWx0x5X9pOsIN80WzPVNz4oEvHe00EyLFsOjr1Ccyvc3jPW lZzTvexr6U5Ng/Yr0nId7LE4onGBVQPToN8AnabM1Uhl2HGiZCgUBVO+q/Vz5ATb aGUcBDDQPpR+qOXbygkFQh7reZI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:cc:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=07CICyeXJovyeuk1LHB6sj brghY=; b=iIQg9nlk5NsfLm/EgCtXoEORCPUSF+VlLlKROX6Wqm20FRwirTTyLK ZrCyY0ZkLkQx+4nyAovE7DZpgkym0rCUyrH7bR3YAqGkVeBxZ6hLLM6xwG+PJ+Db K3pCee2btAvk3oPr0ky2IfQ1pjDoGyO6nKVjwt++gXitF5Vrm4Mb0= Received: (qmail 68089 invoked by alias); 17 Apr 2019 19:44:53 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 68080 invoked by uid 89); 17 Apr 2019 19:44:52 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH] manual: don't ignore SIGCHLD when calling waitpid To: Adhemerval Zanella References: <4498cfca-28d0-f868-b46c-562050447bf5@linaro.org> From: Paul Eggert Openpgp: preference=signencrypt Cc: libc-alpha@sourceware.org Message-ID: Date: Wed, 17 Apr 2019 12:44:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <4498cfca-28d0-f868-b46c-562050447bf5@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/17/19 12:05 PM, Adhemerval Zanella wrote: > My understanding of the example is for interactive shells (shell_is_interactive), > the idea is only to get child information to the explicit launched processes done > by launch_process, so ignoring and reseting SIGCHLD seems ok. Sure, but the problem is that launch_process is used only in the child, which means the parent shell always ignores SIGCHLD, so if the parent calls do_job_notification it won't get any info about children. Perhaps this could be fixed by documenting do_job_notification as requiring that SIGCHLD be reenabled before calling it, but that's pretty confusing. Also the proposed change to the manual is not enough, as there's other text saying that the sample shell program ignores SIGCHLD. Presumably this is to avoid races in the parent shell. But if SIGCHLD causes races in the parent, then the parent typically should block SIGCHLD instead of ignoring it and similarly for the other signals - otherwise the fact that the signals arrived will be lost. So the whole example needs to be rethought.