Mail Archives: cygwin/2000/11/13/01:17:27
the timewarp here is because this has been a "back burner" issue for me,
and I've finally gotten back to it.
At 10:40 10/2/00 -0400, Chris Faylor wrote:
>On Sun, Oct 01, 2000 at 10:41:28PM -0500, Chris Abbey wrote:
> >Does anyone out there really understand signal handling in cygwin?
>Yes. Intimately.
EXCELLENT! :)
>SIGQUIT != CTRL-BREAK.
ok, very good point. I've gone back and looked at the code,
for Windows it registers SIGBREAK instead of SIGQUIT as it
does on every other platform, grrr.
> >ctrl-break signals the child process and it begins to work, but
> > almost immediately the process is terminated. close, but not
> > quite there.... :(
ok, even though I had the wrong signal name, *this* case
should not have been effected.
>#include <stdio.h>
>#include <sys/signal.h>
>
>int
>ouch (int sig)
>{
> printf ("sig %d\n", sig);
> return;
>}
>
>
>int
>main (int argc, char **argv)
>{
> signal (SIGQUIT, ouch);
> sleep(20);
> puts ("exiting");
>}
>
>seems to work fine for me.
yes, works fine for me too, now let me make sure I understand it.
the call to signal registers the handler, then it sleeps for
twenty seconds allowing me time to send it the signal from another
shell, then exits.
>Same as UNIX: sigprocmask, etc.
suggestion for further reading?
> >I really suspect that the problem is that the child process registers
> >for signals via the win32 API, not the cygwin API. Is there any way I
> >can work around this? Any suggestions welcomed, as I said this is really
> >getting annoying.
>
>I suspect that your assumptions that SIGQUIT == CTRL-BREAK are your major
>problem. I don't see any hint of a "SIGQUIT" in the MSDEV includes and
>a search for SIGQUIT at the MSDDN online search does not yield anything
>which indicates that it should be exercised when you press CTRL-BREAK.
yup, shoulda been talking about SIGBREAK.
>Cygwin equates CTRL-BREAK with CTRL-C. Both send a SIGINT to the process.
but that doesn't jive with the behaviour I'm seeing. If I start the program
and hit ctrl-Break it *starts* to execute the signal handler then get's killed.
if I start the program and send it SIGINT via 'kill -SIGINT <pid>' then it
just get's killed, the signal handler does not appear to be called at all.
now the forces of openness
have a powerful and
unexpected new ally
http://ibm.com/linux/
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -