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: <01a401c19892$2f5fa8d0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin AT cygwin DOT com>
References: <000f01c19766$549cb8e0$0200a8c0 AT lifelesswks> <017b01c1976a$21451e70$c51811ac AT brokat DOT de> <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>
Subject: Re: bash/cmd CTRL-C problem...
Date: Wed, 9 Jan 2002 09:16:55 +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: 08 Jan 2002 22:16:56.0281 (UTC) FILETIME=[2EE9DC90:01C19892]

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

> 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 :}. However, note the
requirements to drop the signal:
* The process startup must be in _P_OVERLAY mode.
* The new process must have successfully been created.
* Their must be no cygwin parent to the spawning process, or the
spawning process must be the top of the process group.
* The new process must not have signalled it's creation back to us.

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

> Also, your change seems to make no distinction between a spawned and
> execed process.  It looks like if the user had called spawn, a CTRL-C
> would just cause the parent process to die.

No, if the user had called spawn, with mode != _P_OVERLAY, then this
patch makes no difference.
If the user had called spawn with mode == _P_OVERLAY and it's spawning a
cygwin program then the user will notice no difference, or worst case a
_perfectly timed_ CTRL-C is ignored. (Note: Ctrl-Break is not altered).
If the user had called spawn with mode == _P_OVERLAY and it's spawning a
non cygwin program then the user will notice no difference - the non
cygwin program will handle it's own CTRL-C.




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