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: Thu, 10 Jan 2002 10:53:19 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: bash/cmd CTRL-C problem...
Message-ID: <20020110155319.GA24341@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20020108161950 DOT GC22944 AT redhat DOT com> <01a401c19892$2f5fa8d0$0200a8c0 AT lifelesswks> <20020109003913 DOT GA28328 AT redhat DOT com> <042a01c198a6$b03bb2a0$0200a8c0 AT lifelesswks> <20020109005523 DOT GA28659 AT redhat DOT com> <044301c198a8$8f0b61a0$0200a8c0 AT lifelesswks> <20020109011311 DOT GB28659 AT redhat DOT com> <045301c198ab$3659f820$0200a8c0 AT lifelesswks> <20020110024653 DOT GA31361 AT redhat DOT com> <010701c199ac$ca415b30$0200a8c0 AT 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

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/