[Gc] GC, signals and interrupts

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Fri Oct 10 14:08:21 PDT 2008

[I posted this through gmane, but did not show up in the archives, hence I
decided to try my luck again, but via ordinary mail]


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.

Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)

More information about the Gc mailing list