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
Date: Tue, 8 Jan 2002 19:39:13 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: bash/cmd CTRL-C problem...
Message-ID: <20020109003913.GA28328@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01a401c19892$2f5fa8d0$0200a8c0@lifelesswks>
User-Agent: Mutt/1.3.23.1i

On Wed, Jan 09, 2002 at 09:16:55AM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf AT redhat DOT com>
>
>
>> On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
>> >FWIW this patch (Chris where should I put the in_stub declaration)
>>
>> There is already an indicator that an execed process is running --
>> hExeced, so I don't think you need the 'in_stub' thing.
>
>No, hExeced is set far too early... There is a very narrow window where
>we want to ignore CTRL-C.

We want to deal with CTRL-C as soon as the process enters its "stub
state".  That's when hExeced is set.

>>However, it seems to me that this solution is racy.  If a person types
>>CTRL-C during process startup, it's possible that a cygwin process will
>>never see a true cygwin signal.  Hmm.  I guess this race is already in
>>signal_exit, in fact.  I have to fix that.
>
>Yes there is.  I asked for thoughts, but got none :}.

Yes, as I mentioned, I wasn't actually interested in debugging this
myself but I would investigate patches.

>However, note the requirements to drop the signal:
>* The process startup must be in _P_OVERLAY mode.

I completely missed this before.  Sorry.

>* The new process must have successfully been created.

It wouldn't be much of a process if it didn't exist, I guess.

>* Their must be no cygwin parent to the spawning process, or the
>spawning process must be the top of the process group.

Yes.  It must be at the top of a process group.  Period.

>* 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."

>> Regardless, it is not always the correct behavior for CTRL-C just do
>> the "default thing".  If the execed process is supposed to be ignoring
>> SIGINT then it isn't right for the process to exit.
>
>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.

>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.

>> 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.

cgf

--
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/