Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <042a01c198a6$b03bb2a0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin AT cygwin DOT com>
References: <007b01c1977d$6093f520$0200a8c0 AT lifelesswks> <20020107165105 DOT GB4652 AT redhat DOT com> <037a01c197cf$1d0a4000$0200a8c0 AT lifelesswks> <20020107234555 DOT GA11984 AT redhat DOT com> <03ca01c197d9$8a16c510$0200a8c0 AT lifelesswks> <20020108002140 DOT GA12820 AT redhat DOT com> <03f001c197dd$7a9bec10$0200a8c0 AT lifelesswks> <013201c19812$2125e750$0200a8c0 AT lifelesswks> <20020108161950 DOT GC22944 AT redhat DOT com> <01a401c19892$2f5fa8d0$0200a8c0 AT lifelesswks> <20020109003913 DOT GA28328 AT redhat DOT com>
Subject: Re: bash/cmd CTRL-C problem...
Date: Wed, 9 Jan 2002 11:43:41 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 09 Jan 2002 00:43:42.0202 (UTC) FILETIME=[AFA6C5A0:01C198A6]

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