Mail Archives: cygwin/2006/02/24/16:38:17
On Fri, Feb 24, 2006 at 03:22:05PM -0500, Paul Clements wrote:
>On Thu, Feb 23, 2006 at 04:40:33PM -0500, Christopher Faylor wrote:
>>Actually, I spoke too soon. I don't understand your analysis. You
>>make this statement:
>
>>>However, if the queueing of the blocked signal happens right after the
>>>signal mask change, then we miss the signal.
>
>>but I don't understand how you came to this conclusion. If the signal
>>mask changes, then the queue should be flushed -- that's what the
>>__SIGFLUSH is for. So, even if something is added to the queue while
>>the mask is changing, the function which changes the mask should
>>eventually call send_sig to cause the wait_sig thread to run the queue.
>
>>So, this patch would seem to be a band-aid over some other problem.
>
>OK, I think I see what is happening now:
>
>set_signal_mask() does indeed call sig_dispatch_pending() to do a flush
>when the signal mask changes. However, when the sigq is empty,
>sig_dispatch_pending() just returns! See:
>
>
>sig_dispatch_pending (bool fast) { -if (exit_state || &_my_tls ==
>_sig_tls || !sigq.start.next) +if (exit_state || &_my_tls == _sig_tls)
I always wondered if that "optimization" was right and now I see that it is
obviously racy. I've removed it from the source.
>Unfortunately, when I make this change, everything hangs. Not sure what
>the issue is there. Any ideas?
Not until I ran the test suite, waited five minutes and saw an error.
Attaching gdb to the running process shows another problem. I'll check
in a fix for this, too.
>(please CC, I'm not on the list)
I've cc'ed you this once however please join the mailing list if you
want to talk about cygwin.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -