Ooops, to the list as well.
---------- Forwarded message ----------
From: Nikodemus Siivola <nikodemus@...>
Date: Mon, Jan 19, 2009 at 8:17 AM
Subject: Re: [Sbcl-devel] patch: SB-EXT:*BEFORE-GC-HOOKS*
To: Gábor Melis <mega@...>
On Sun, Jan 18, 2009 at 9:38 PM, Gábor Melis <mega@...> wrote:
> Don't you need an allow-with-interrupts for that with-interrupts to
> actually do something?
Not unless WITHOUT-INTERRUPTS is broken: if WITH-INTERRUPTS is
lexically nested within the only WITHOUT-INTERRUPTS, no A-W-I is
> In general, the problem with this patch is that in a multithreaded
> environment there is often a race to do gc between threads. When
> acquiring the lock it should be checked that *gc-pending* is still not
> nil, and punt on gc if it is. This is to avoid a lot of unneeded gcs.
> Naturally the after gc hooks should only be run if gc was done in that
> thread. Same for before gc hooks. How to run the before hooks only when
> it's decided that gc will actually be done in this thread (i.e. holding
> the *already-in-gc* lock with *gc-pending*), I don't know.
I don't quite agree: even if the GC is punted, the hooks could be run.
Call it a trivial GC if you will. My reasoning is that I don't see how
both could be elided unless we allow user code to run while holding
the lock, and we want to make them it possible to pair them for
> All in all, sub-gc needs fixing as it is and once fixed it will become
> apparent that before hooks are not an easy add on. At least, I don't
> see how they can be supported.
> I'm in doing a cleanup of signal handling and gc triggers (needless to
> say there are a few bugs there), touching sub-gc as well. I'm aiming to
> commit it early 1.0.25.xxx. Things may be a bit clearer by then.
Ok, I'll hold off on this till then.