This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: Signal handling tune up.
- From: Christopher Faylor <cgf at redhat dot com>
- To: cygwin-patches at cygwin dot com
- Date: Mon, 18 Aug 2003 20:58:32 -0400
- Subject: Re: Signal handling tune up.
- References: <3.0.5.32.20030818201736.0080e4e0@mail.attbi.com>
- Reply-to: cygwin-patches at cygwin dot com
On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote:
>5)
>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
occurrence.
However, this does demonstrate a flaw in wait_sig. It exhausts the sigtodo
array based on the last received type of signal. So, if process a sends ctrl-c
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.
I still have a hard time seeing how this could happen with any regularity
but it is definitely something I will fix.
Thanks,
cgf