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: bash/cmd CTRL-C problem...

----- Original Message -----
From: "Christopher Faylor" <>
> >* 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
parent to
> be responding to CTRL-Cs when the child has indicated "Yep!  I'm a
> 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
> >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
> >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

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
> >> 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:
Bug reporting:

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