From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3901 invoked by alias); 10 Jan 2002 15:53:08 -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 3874 invoked from network); 10 Jan 2002 15:53:08 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (12.107.208.154) by sources.redhat.com with SMTP; 10 Jan 2002 15:53:08 -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 g0AFr7w29110 for ; Thu, 10 Jan 2002 10:53:07 -0500 Received: (from cgf@localhost) by cgf.cipe.redhat.com (8.11.6/8.8.7) id g0AFrJt24622 for cygwin@cygwin.com; Thu, 10 Jan 2002 10:53:19 -0500 Date: Thu, 10 Jan 2002 07:53:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: bash/cmd CTRL-C problem... Message-ID: <20020110155319.GA24341@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20020108161950.GC22944@redhat.com> <01a401c19892$2f5fa8d0$0200a8c0@lifelesswks> <20020109003913.GA28328@redhat.com> <042a01c198a6$b03bb2a0$0200a8c0@lifelesswks> <20020109005523.GA28659@redhat.com> <044301c198a8$8f0b61a0$0200a8c0@lifelesswks> <20020109011311.GB28659@redhat.com> <045301c198ab$3659f820$0200a8c0@lifelesswks> <20020110024653.GA31361@redhat.com> <010701c199ac$ca415b30$0200a8c0@lifelesswks> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010701c199ac$ca415b30$0200a8c0@lifelesswks> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2002-01/txt/msg00631.txt.bz2 On Thu, Jan 10, 2002 at 06:59:54PM +1100, Robert Collins wrote: >> I was going back over this thread before checking in a change to see if >> I'd missed something. >> >> I just realized that I didn't address this concern. Don't know if it >> matters but... >> >> The difference between the SIG_IGN way and the "return TRUE" way is >> that the SIG_IGN way stops the current process from responding to >> a cygwin signal but still lets it respond to a Windows "signal". That >> means that the code in ctrl_c_handle can do its job, if it has to. > >Huh? I actually did the reverse - returning TRUE only prevented >responding to a windows signal, but allowed responding to a cygwin >signal. Yep. Wrong behavior. The stub should respond to windows signals while the child is initializing. Remember this discussion? >>If we always "return TRUE" in the exec case, then there will be some >>situations where the SIGINT is not delivered to the rest of the process >>group since the code in ctrl_c_handler would be short circuited. > >I don't believe that is the case: Every console process attached to >that console independently recieves the windows signal. Only one has >been disabled. So the execing process's children will still recieve >the windows signals and the cygwin signals. The newly executed subprocess may not have yet set up ctrl_c_handler so it will not do anything but die when CTRL-C comes in. The stub will ignore the CTRL-C. That means that the rest of the processes in the process group will not receive a CTRL-C. >> My SIG_IGN "solution" is wrong, too, though. The SIG_IGN would be >> inherited by the exec'ed process. Then the execed process would never >> see a cygwin SIGINT signal. > >Yes. I still believe that return TRUE is a good solution... but if >you've solved the obvious behaviour I'll be quite now :}. I guess I'm having a hard time understanding why I couldn't just say "race" and have you understand that there is a race but I'll stop now, too. 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/