X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 21 Sep 2009 11:33:56 -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: <20090921153356.GA16100@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>  <20090919144319 DOT GA31739 AT ednor DOT casa DOT cgf DOT cx>  <loom DOT 20090921T103139-168 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20090921T103139-168@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 Mon, Sep 21, 2009 at 08:32:47AM +0000, Waldemar Rachwal wrote:
>Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
>>On Sat, Sep 19, 2009 at 10:31:58AM +0000, Waldemar Rachwal wrote:
>>>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,
>>
>>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.
>
>To satisfy the condition (quoted from posix) "action is anything other
>than to ignore", SIGCHLD (and all other signals which default action is
>to ignore) must be setup a handler even if it seems "not useful".
>Being blocked is not sufficient.

Ok.  Yes, I was wrong about the meaning of action but, as I said, this
works fine on Linux without setting a dummy handler.  The reason for that
is that SIGCHLD is, by default, set to SIG_DFL not SIG_IGN. To quote
from Roland McGrath (one of the glibc maintainers):

"When a signal is set to SIG_IGN, it's true that the signal may be
dropped at generation time and never recorded.  But POSIX does not allow
this for signals set to SIG_DFL, even when the default action for the
signal is to ignore it.  In this case, the rule when the signal is
blocked is that it must become pending--this allows a sigaction call
before unblocking the signal to change its action."

This comment comes from a bug report which eventually resulted in a fix
to the linux kernel.

>>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.
>
>Completely agree.  I hope not to start 3rd thread on the same problem
>anymore (the root cause of the problem from
>http://sourceware.org/ml/cygwin/2009-08/msg00797.html is exactly the
>same as from this thread).

It is not exactly the same since SIGWINCH is special when running in a
console app and will not be delivered reliably.

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