Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Tue, 8 May 2001 19:08:10 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: Re: Brainstorming a fix for CTRL-C handling in an emacs shell buf fer (non-TTY)
Message-ID: <20010508190810.A25048@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
References: <8F23E55D511AD5119A6800D0B76FDDE11E102C AT cpex3 DOT channelpoint DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <8F23E55D511AD5119A6800D0B76FDDE11E102C@cpex3.channelpoint.com>; from troy.noble@channelpoint.com on Tue, May 08, 2001 at 04:26:09PM -0600

On Tue, May 08, 2001 at 04:26:09PM -0600, Troy Noble wrote:
>> >I immediately got a SIGINT in the child process, even before its
>> >CTRL-C handler got invoked.
>
>> That's a "Windows" SIGINT, which is the only thing that gdb can
>> detect.  A Cygwin SIGINT is a different thing entirely.  Since Cygwin
>> has the full complement of Windows signals, it uses another complicated
>> method for sending signals between processes.
>
>> Running in strace would tell whether you received a SIGINT or not.  You'd
>> see the signal_thread responding to a SIGINT.
>
>This is what I get.
>
>Didn't see anything before the ctrl_c_handler output that looked like an
>incoming SIGINT from bash.exe.  Also no hit on a serch for "signal_thread".
>What is "[unknown (0x7FC)]" indicated.  Could that be the signal thread?

Actually, I should have checked before I responded.  The name of the thread
is just "sig".  The unknown thread is started by Windows when it wants to
deliver a CTRL-C.

>Interestingly, running "strace ls -lR" the child doesn't get the SIGINT
>until after it's ctrl_c_handler runs and it sends itself a SIGINT.

Oh well.  That sounds right, since strace isn't a cygwin application
the pid_exists (t->getpgid ()) will == FALSE and the process will send
a SIGINT to itself.

The only way to test this is to run strace on the bash process itself
and then watch for SIGINTs when a subprocess is running.  I don't think
you'll see them, though.

>Also interesting that the code inside ls.exe now thinks that
>t->getpgid() == myself->pid.  How does that happen?

Because strace acted as a barrier in this case.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple