Mail Archives: cygwin/2001/05/08/19:11:18
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
- Raw text -