Create a gist now

Instantly share code, notes, and snippets.

anonymous /gist:1096804
Created Jul 21, 2011

What would you like to do?
Inconsistent SIGINT behaviour - why?
The following (a small C program and a python script that calls it)
behave differently across various Unixes.
In some of them (e.g. Debian stable), the C app gets the signal,
the message is printed fine from the signal handler and the script
finishes fine. In others (e.g. a two year-old Ubuntu and an OpenBSD)
the signal is lost, and therefore the message is not printed at all,
and the script waits forever...
The signal is ALWAYS delivered, if in the python script, I change this...
mysub=subprocess.Popen("./cryInAbort", shell=True)
into this...
mysub=subprocess.Popen("./cryInAbort", shell=False)
So it appears that in some Unixes the intermediate shell "eats" the SIGINT,
while in others it forwards it to the child process (the C program).
I took care to only call re-entrant functions in the signal handler
so this doesn't seem to be related to my C code - it looks as if
signal handling behavior within "/bin/sh" (the default shell used
by Python to spawn things) is not "stable" across Unixes...
Am I doing something wrong?
// First, the C code that cries when it gets SIGINT
#include <signal.h>
#include <unistd.h>
void my_handler()
static const char msg[] = "Goodbye - test was OK.\n";
_exit (0);
int main()
(void) signal (SIGINT, my_handler);
while (1);
#!/usr/bin/env python
# Then, the Python script that tests it by sending SIGINT:
import subprocess,signal,time
mysub=subprocess.Popen("./cryInAbort", shell=True)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment