----- Original Message ----- From: "Christopher Faylor" <[EMAIL PROTECTED]> > >* 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 > process."
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 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 > >CTRL-C. > > 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. 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 > >recieved. > > 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 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 > 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 :}. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
