This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Signal handling tune up.

At 08:58 PM 8/18/2003 -0400, Christopher Faylor wrote:
>On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote:
>>This is just an observation, about sig_handle (int sig, bool thisproc)
>>The thisproc argument is set to "rc != 2" in the sigthread. However
>>it is possible for several signals to occur simultaneously and a
>>signal can be processed with rc == 2 even when generated by the 
>>current process (or conversely). This could cause a SIGINT to be 
>>ignored (or not) when it shouldn't (something like that was discussed
>>on the list recently).
>>I don't fully understand the use of thisproc and have no suggestion. 
>Are you saying that that someone reported execing a process, hitting
>ctrl-c, and having another process simultaneously sending CTRL-C's to
>the exec'ed stub?  I have a hard time seeing how that could be a common

No. But you just explained what I didn't understand about the code.
>However, this does demonstrate a flaw in wait_sig.  It exhausts the sigtodo
>array based on he last received type of signal.  So, if process a sends
>to itself and "at the same time" process b sends ctrl-c to process a,
>then the signal will be randomly processed as coming from either process a
>process b.  If the signal is handled as coming from process b, process a
>will never get the notification it needs.

Yes, that's what I had in mind. There are also the sig_dispatch_pending (0)
in (and other places) that generate events with rc == 2 even though 
they are local.
I don't understand their role.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]