This is the mail archive of the
mailing list for the Cygwin project.
Re: bash/cmd CTRL-C problem...
----- Original Message -----
From: "Christopher Faylor" <email@example.com>
> >* 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
> to *ever* send a CTRL-C in your scenario. I don't see why it matters
> the subprocess has been reparented. You especially don't want the
> be responding to CTRL-Cs when the child has indicated "Yep! I'm a
What I meant was, that once the child has signaled it's a cygwin
process, we terminate the stub immediately anyway. But yes, perhaps we
should not re-enable CTRL-C processing.
> >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
> >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
> >If the execed process is not a cygwin process, then it will handle
> >not) CTRL-C itself. We should *not* force quit it when the stub
> 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
Hmm. Well CTRL-C and CTRL-BREAK are identified separately. I'll go have
a browse of the lists I guess.
> >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.
True. The issue IMO is whether we assume the child will do the right
thing, or whether we assume the child won't. If it's a cygwin child
it'll do the right thing after being reparented. If it's a non-cygwin
child it'll do the right thing on it's own.
> >> Also, your change seems to make no distinction between a spawned
> >> 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
> away without some kind of additional communication between the parent
> the child.
True. The problem is that we can't communicate with non-cygwin children.
So there will always be a window (from when a process is created to when
we find out it's a cygwin process) where we have to guess :}.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html