On Fri, Sep 18, 2009 at 04:57:56PM +0000, Waldemar Rachwal wrote: >A problem seems very close to one described in >http://sourceware.org/ml/cygwin/2009-08/msg00797.html >and now I don't think it can be easily explained by >"limitation in Cygwin's implementation of SIGWINCH". > >What I did this time... > >When I fork children and next observe their termination in >the parent process by means of sigwait(), >*none* of the SIGCHLD signals is returned immediately until some other >"regular" signal, let's say SIGINT, is sent to the parent. > >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(). >What makes these signals "special" is that their default action is `to >IGNORE' and to be useful for sigwait() they need to register some dummy >handler. >Maybe this has something to do why sigwait() doesn't work as >expected.
Thanks for the test case. The problem has nothing to do with anything "special" about SIGCHLD. It's a signal like any other signal. 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. This will be fixed in the next snapshot. 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
