|Jeroen Demeyer on Mon, 18 Apr 2005 13:41:11 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: GP handling of SIGINT (Linux)|
Karim Belabas wrote:
* Jeroen Demeyer [2005-04-17 21:35]:Hello list, while hacking with GP and shell scripts under Linux, I noted the following: When using GP non-interactively (gp -f -q <commands.gp >output),it only handles a SIGINT once. The first SIGINT is caught and interrupts the current command (as usual), but any further SIGINTs do nothing. I don't understand how come this behaviour is different from an interactive GP, where multiple SIGINTs can be cought.Is this a feature or a bug?It's a bug, which we've not been able to trace so far. See
Looking at the code, I have an idea on what's going wrong. The problem seems to be with the use of longjmp(). This causes the function gp_sighandler() never to return, so the rest of the program is treated as being inside the signal handler. By default a signal can never occur during a signal handler.
A very ugly hack around this is to change this default. I have done this in attached patch. I can only say it fixes my problem, but it could very well break things. The behaviour is also likely to be OS-dependent.
? build.sh ? config/linux-i686-tmp19989 Index: src/language/es.c =================================================================== RCS file: /home/cvs/pari/src/language/es.c,v retrieving revision 1.168 diff -u -r1.168 es.c --- src/language/es.c 6 Apr 2005 19:43:13 -0000 1.168 +++ src/language/es.c 18 Apr 2005 11:31:22 -0000 @@ -2741,7 +2741,15 @@ #ifdef WINCE return SIG_IGN; #else - return signal(sig,f); + struct sigaction sa; + struct sigaction oldsa; + + sa.sa_handler = f; + sigemptyset(&sa.sa_mask); + sa.sa_flags = SA_NODEFER; + + if (sigaction(sig, &sa, &oldsa)) return NULL; + return oldsa.sa_handler; #endif }