From owner-freebsd-questions@FreeBSD.ORG Tue May 21 05:57:00 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9619B9EF for ; Tue, 21 May 2013 05:57:00 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2F0198 for ; Tue, 21 May 2013 05:57:00 +0000 (UTC) Received: from r56.edvax.de (port-92-195-231-35.dynamic.qsc.de [92.195.231.35]) by mx01.qsc.de (Postfix) with ESMTP id 9BAF63CE3D; Tue, 21 May 2013 07:56:53 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id r4L5v2cZ004419; Tue, 21 May 2013 07:57:03 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Tue, 21 May 2013 07:57:02 +0200 From: Polytropon To: Noel Hunt Subject: Re: signal vs. sigaction and SIGCHLD Message-Id: <20130521075702.6d59bbac.freebsd@edvax.de> In-Reply-To: References: Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 05:57:00 -0000 On Tue, 21 May 2013 15:24:26 +1000, Noel Hunt wrote: > If I recompile with `#undef SIGACTION', waithandler is not > called. > > I should add that even with the sigaction(2) interface, without > the `sigprocmask' call, it still doesn't work, which suggests > that SIGCHLD is being blocked. > > Can anyone explain why? >From reading "man 3 signal", I get the following impression: No Name Default Action Description 20 SIGCHLD discard signal child status has changed The default action is to discard the signal, so the following paragraph could make sense: The sig argument specifies which signal was received. The func procedure allows a user to choose the action upon receipt of a signal. To set the default action of the signal to occur as listed above, func should be SIG_DFL. A SIG_DFL resets the default action. To ignore the signal func should be SIG_IGN. This will cause subsequent instances of the signal to be ignored and pending instances to be discarded. If SIG_IGN is not used, further occurrences of the signal are automatically blocked and func is called. >From my limited understanding, maybe this could help you find an explanation of the observed behaviour? Also compare /usr/include/sys/signal.h for the definition of the involved typedef's. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...