[gambit-list] Interrupted in wait-for-io

Marc Feeley feeley at iro.umontreal.ca
Wed Jan 4 10:28:58 EST 2006


On 4-Jan-06, at 12:36 AM, Christian wrote:

> At 10:18 Uhr -0500 03.01.2006, Marc Feeley wrote:
>> CTRL-C does not generate an exception.  It simply calls the  
>> current user-interrupt-handler.
>
> Ok, thanks, that makes perfect sense.
>
> Two small followup questions about things I might need in the future:
>
> - can other signals than SIGINT be catched, too? I guess that you  
> haven't added that since it's platform specific. I might write a  
> small C layer for my programs on unix, but then my question is: how  
> do I register an interrupt callback in gambit's runtime (I guess  
> I'll have to save the signal number and values into some global and  
> then let gambit run a callback synchronously at a safe point)?
>

It is possible using undocumented procedures.  Here's what you want:

(c-declare #<<c-declare-end

#include <signal.h>

void handler (int sig)
{
if (sig == SIGUSR1)
     ___EXT(___raise_interrupt) (___INTR_6);
else
     ___EXT(___raise_interrupt) (___INTR_7);
}

void install_SIGUSR_handlers ()
{
   signal (SIGUSR1, handler);
   signal (SIGUSR2, handler);
}

c-declare-end
)

(define install-SIGUSR-handlers
   (c-lambda () void "install_SIGUSR_handlers"))

(define (install-handlers)
   (##interrupt-vector-set! 6 (lambda () (println 'got-SIGUSR1)))
   (##interrupt-vector-set! 7 (lambda () (println 'got-SIGUSR2)))
   (install-SIGUSR-handlers))

(install-handlers)

(define my-pid (##os-getpid))

(display "executing kill -USR1\n")

(shell-command (string-append "kill -USR1 " (number->string my-pid)))

(display "executing kill -USR2\n")

(shell-command (string-append "kill -USR2 " (number->string my-pid)))

(display "done\n")

; Output:
;
; executing kill -USR1
; got-SIGUSR1
; executing kill -USR2
; got-SIGUSR2
; done

> - maybe it's rather theoretical, but there is probably a time frame  
> between the start of a program and the time when it sets user- 
> interrupt-handler where sending SIGINT still makes the program  
> "hang" in the debugger. Could gambit delay installing of a SIGINT  
> signal handler so that the program behaves in the default way until  
> the user actually installs a handler?(*) That should also be better  
> if gambit is to be embedded in a C program which wants to catch  
> signals itself.
>

Good point.  Currently Gambit, under Unix, starts off with SIGINT  
terminating the program (that's the default Unix SIGINT handler),  
then the runtime system installs a handler that ignores SIGINT, then  
it installs a handler that starts a REPL.

I'm planning to change this so that the default user-interrupt- 
handler behaves like exceptions, i.e. the default will be to  
terminate the program after displaying "*** INTERRUPTED IN ...".   
With the runtime option "-:d" the system will instead start a REPL.   
With the runtime option "-:d0" the program will terminate silently.   
However, when inside a REPL (such as the one normally started in  
interactive mode), a SIGINT will start a nested REPL.

> (*) that leads to another question I've been wondering about:  
> parameterize doesn't accept procedures which aren't parameters (it  
> checks their type). This makes the above suggestion impossible to  
> be implement transparently of course, since it would require  
> running code other than just for setting the dynamic value (**).

I don't understand what you mean.

> What's the reason for this restriction?
>

Parameters are special procedures that contain a key.  This key is  
used to lookup the binding of the parameter.  The machinery is quite  
complex (see _thread.scm).

> ((**) without this, the user would have to run some (user-interrupt- 
> initialize!) hook first -- at least, that might be better for  
> thread safety?)
>
> Thanks
> Christian.
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list




More information about the Gambit-list mailing list