Re: bash/cmd CTRL-C problem...

["Robert Collins" <robert.collins@itdomain.com.au>]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.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
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/