[Gc] GC, signals and interrupts

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Tue Oct 21 23:39:26 PDT 2008

Hmm, seems even after subscribing to the list this mail got bounced?

Thanks anyway for your detailed answer. I will just try to make it
clear how I am currently implementing our signal handler

On Wed, Oct 22, 2008 at 2:40 AM, Boehm, Hans <hans.boehm at hp.com> wrote:
>> 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.
> I'm not sure I understand your scheme exactly.
> You set a flag in the mainline code to disable the handler?

Yes, we store all information about a lisp thread in a block of mmaped
memory. This block is scanned at garbage collection time by a routine
we register with your library. When a signal arrives, the handler
checks a flag in this block of memory. If the flag is
disabled_signals=0, then it handles the signal, allowing even to
invoke arbitrary lisp code. Otherwise, if disable_signals=1, it stores
information about the signal in a queue, mprotects this block of
memory and returns. Whenever we are back in the lisp code, access to
the thread information, or the statement that changes disable_signals
back to 0 cause a SIGBUS signal so that the handler is entered again.
This time it knows it has to handle all pending signals.

> You don't want to run Lisp code while the collector is active.
> Memory allocation probably won't work correctly at that stage.
> With threads, it's likely to deadlock, since the GC will already hold the lock.

I guessed so. I now surround allocation code with the code to defer
signals as explained before. In order to make this less expensive, I
originally planned to inline the allocation code much like bigloo does
right now. I am just finding out that almost no linux distribution
installs the private headers, making this pretty much impossible.
Could you enforce the opposite? Perhaps advising distributions to
install all of GC?

Thanks again for the rest of the information!


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

More information about the Gc mailing list