Signal handling tune up.

Christopher Faylor
Tue Aug 19 20:46:00 GMT 2003

On Tue, Aug 19, 2003 at 04:30:06PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>> >Don't we have the same problem today?
>> >
>> >Handler is running with current mask M1, old mask M0
>> >New signal occurs, sigthread prepares sigsave with new mask M2, old mask M1
>> > but is preempted before setting sigsave.sig
>> >Handler terminates, restores M0
>> >sigthread resumes and starts new handler. It runs with M2 and restores
>> >M1 (instead of M0) at end.
>> Is this any different from UNIX?  Some races in signal handling are
>> inavoidable, IMO.  I guess you could make things slightly more
>> determinstic by setting a lock.  Probably UNIX has the luxury of being
>> able to tell the process handling a signal to stop working for a second
>> while it fiddles with masks.  We don't have any reliable way of doing
>> that.
>Here is a safe way.
>1) change sigsave to contain the incremental mask bits, set by sigthread
>   (instead of old mask and new mask) 

And while you are in the process of saving the incremental bits, they
are in the process of being changed == race.  I don't see why this adds
anything.  I'm also not sure that this is posix-sanctioned behavior.


More information about the Cygwin-patches mailing list