[Gc] Garbage collector and signals / interrupts

Juan Jose Garcia-Ripoll juanjose.garciaripoll at gmail.com
Wed Oct 8 14:40:05 PDT 2008


I was wondering whether there are some simple guidelines on using the garbage
collector with our Common Lisp interpreter. Roughly I am now worrying about the
following issues:

1 - ECL needs to detect stack overflows. Currently by installing the handler
_before_ calling GC_init, it seems that the garbage collector honors our handler
and it gets called for any SIGSEGV related to stack overflows and not to GC. Is
this ok?

2 - Not long ago, we used to call arbitrary lisp code from the signal handler. I
learnt the hard way this is evil and thus I am now delaying signals by using a
global flag. Should I also prevent interrupts by setting this flag around calls
to the garbage collector? I insist our handler is not delaying GC signals, only
SIGINT and the like.

3 - If we are not to prevent signals from happening during allocation and
garbage collection, is it safe to use longjmp() from the signal handler and jump
to a point before the call to the allocator (*)? I presume not and then the
answer to 2 should be really: please defer signals.

4 - Skimming the mailing list I learnt that the library uses signals to suspend
threads. Will this cause failure of C functions or only those related to I/O?
Should I then surround all those calls with GC_start/end_blocking?

5 - What signals should we _not_ handle? Or is it ok if we just install our
handlers before GC_init? In particular, for fast detection of pending signals I
am currently using mprotect to block writes to the disable_signal flag. That
means we need to be able to handle SIGBUS for regions which are not garbage

6 - Am I missing other questions? :-)

Thanks in advance,


(*) I know using longjmp() from a signal handler is typically a bad practice,
but as I said before, we only do that when we know the handler was only invoked
from safe code and did not interrupt calls to the C library.

More information about the Gc mailing list