Re: Brainstorming a fix for CTRL-C handling in an emacs shell buf fer (non-TTY)

[Christopher Faylor <cgf at redhat dot com>]

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