This is the mail archive of the
mailing list for the Cygwin project.
Re: bash/cmd CTRL-C problem...
On Wed, Jan 09, 2002 at 09:16:55AM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <email@example.com>
>> On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
>> >FWIW this patch (Chris where should I put the in_stub declaration)
>> There is already an indicator that an execed process is running --
>> hExeced, so I don't think you need the 'in_stub' thing.
>No, hExeced is set far too early... There is a very narrow window where
>we want to ignore CTRL-C.
We want to deal with CTRL-C as soon as the process enters its "stub
state". That's when hExeced is set.
>>However, it seems to me that this solution is racy. If a person types
>>CTRL-C during process startup, it's possible that a cygwin process will
>>never see a true cygwin signal. Hmm. I guess this race is already in
>>signal_exit, in fact. I have to fix that.
>Yes there is. I asked for thoughts, but got none :}.
Yes, as I mentioned, I wasn't actually interested in debugging this
myself but I would investigate patches.
>However, note the requirements to drop the signal:
>* The process startup must be in _P_OVERLAY mode.
I completely missed this before. Sorry.
>* The new process must have successfully been created.
It wouldn't be much of a process if it didn't exist, I guess.
>* Their must be no cygwin parent to the spawning process, or the
>spawning process must be the top of the process group.
Yes. It must be at the top of a process group. Period.
>* The new process must not have signalled it's creation back to us.
I don't think this is right, actually. You basically don't want the stub
to *ever* send a CTRL-C in your scenario. I don't see why it matters that
the subprocess has been reparented. You especially don't want the parent to
be responding to CTRL-Cs when the child has indicated "Yep! I'm a cygwin
>> Regardless, it is not always the correct behavior for CTRL-C just do
>> the "default thing". If the execed process is supposed to be ignoring
>> SIGINT then it isn't right for the process to exit.
>Hangon, look closer.
>If the execed process is a *cygwin* process, then my patch makes no
>difference - the stub is about to quit no matter what, and from a POSIX
>point of view, already has!
You're right. I did need to look closer.
However, IMO, there's a race here. It's possible that killing other
members of the process group is the right thing to do if the child is
still initializing and is unable to handle the CTRL/C correctly. Your
patch eliminates that capability so it may mean that CTRL-C's are lost.
>If the execed process is not a cygwin process, then it will handle (or
>not) CTRL-C itself. We should *not* force quit it when the stub recieves
Oddly enough, that is behavior that I reinstated when I had eliminated
it for a while because people complained that they couldn't kill their
processes. If you don't do that then GUI windows apps don't go away
when you hit CTRL-C, IIRC.
This is the usual cygwin damned if you do/damned if you don't scenario.
>I don't reinstate default behaviour, we simply ignore the keyboard
>generated CTRL-C which we know that the non-cygwin child has already
We know that the child will receive or is about to receive it but we
don't know that the child is about to do the right thing as a result
of receiving it.
>> Also, your change seems to make no distinction between a spawned and
>> execed process.
As I mentioned, this observation was just completely wrong. :-(
I have to think about the race issues here. It seems like you can't get
away without some kind of additional communication between the parent and
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html