From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18699 invoked by alias); 9 Jan 2002 00:39:04 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 18671 invoked from network); 9 Jan 2002 00:39:03 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (12.107.208.154) by sources.redhat.com with SMTP; 9 Jan 2002 00:39:03 -0000 Received: from cgf.cipe.redhat.com (dhcpd72.meridian.redhat.com [172.16.47.72]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g090d2w30875 for ; Tue, 8 Jan 2002 19:39:02 -0500 Received: (from cgf@localhost) by cgf.cipe.redhat.com (8.11.6/8.8.7) id g090dDd28549 for cygwin@cygwin.com; Tue, 8 Jan 2002 19:39:13 -0500 Date: Tue, 08 Jan 2002 16:39:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: bash/cmd CTRL-C problem... Message-ID: <20020109003913.GA28328@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <007b01c1977d$6093f520$0200a8c0@lifelesswks> <20020107165105.GB4652@redhat.com> <037a01c197cf$1d0a4000$0200a8c0@lifelesswks> <20020107234555.GA11984@redhat.com> <03ca01c197d9$8a16c510$0200a8c0@lifelesswks> <20020108002140.GA12820@redhat.com> <03f001c197dd$7a9bec10$0200a8c0@lifelesswks> <013201c19812$2125e750$0200a8c0@lifelesswks> <20020108161950.GC22944@redhat.com> <01a401c19892$2f5fa8d0$0200a8c0@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 X-SW-Source: 2002-01/txt/msg00450.txt.bz2 On Wed, Jan 09, 2002 at 09:16:55AM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Christopher Faylor" > > >> 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/