X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Sat, 19 Sep 2009 10:43:19 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] sigwait bug (SIGCHLD delayed to a next regular signal)
Message-ID: <20090919144319.GA31739@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20090918T184921-716 AT post DOT gmane DOT org>  <20090918213522 DOT GA12527 AT ednor DOT casa DOT cgf DOT cx>  <loom DOT 20090919T114836-897 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20090919T114836-897@post.gmane.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Sat, Sep 19, 2009 at 10:31:58AM +0000, Waldemar Rachwal wrote:
>On Fri, Sep 18, 2009 at 04:57:56PM +0000, Waldemar Rachwal wrote:
>>Apparently, signals like SIGWINCH and SIGCHLD, which are a little bit
>>special, need to be kicked by other signal to be eventually returned by
>>sigwait().
>>
>Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
>>Thanks for the test case.  The problem has nothing to do with anything
>>"special" about SIGCHLD.  It's a signal like any other signal.
>
>I am not sure it's clear.  With regard to sigwait() SIGCHLD like any
>other signal must not only be blocked, additionally like any other
>signal it cannot be ignored, which is not common as only few signals
>are ignored by default, and SIGCHLD and SIGWINCH are in this group.

I was explaining the problem to you.  As I said, SIGCHLD is a signal
like any other signal and if you had tried to use a similar mechanism to
trap, say, SIGINT, you would have seen the same problem.

>POSIX is explicit here:
>
>http://www.opengroup.org/onlinepubs/9699919799/
>
><quote>
>2.4.1 Signal Generation and Delivery
>
>However, a signal can be "blocked" from delivery to a thread.
>
>If the action associated with a blocked signal is anything other than to
>ignore the signal, and if that signal is generated for the thread,
>
>the signal shall remain pending until
>
>it is unblocked,
>
>it is accepted when it is selected and returned by a call to the
>sigwait() function,
>
>or the action associated with it is set to ignore the signal.
></quote>
>
>Simply a signal must be blocked and (actually) not ignored to be
>processed by sigwait().
>
>> Cygwin was not performing sigwait() processing if there was a handler
>> set up for the signal.  Your test case would have worked if you had not
>> set up a dummy handler.
>
>As stated above a handler is the must, otherwise the test won't work
>under POSIX systems.

Since the "above" never mentioned the word handler, I don't see how your
point is valid.  blocked != handler.  blocked == sigprocmask or some
similar mechanism.  You did use sigprocmask in your example.  Setting
the handler doesn't seem to serve any useful purpose since it isn't
being used.  I tested this on linux just to be sure.  Actually, on some
versions of linux you don't even have to block the signal first.

In any event, you provided a test case, I provided a fix.  That's the
desired outcome.  Arguing about this is pointless unless the fix didn't
actually fix anything.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple