Juho Snellman <jsnell@...> writes:
> Hmm... What makes a before-gc-hook more problematic when run in a
> separate thread?
For SBCL the only issue is added cost (and consing) of signalling the
housekeeping thread and waiting for it to finish running those hooks.
I don't know if this would be significant or not.
The user, however, loses the dynamic countour he was interested in.
If before-hooks are run in a separate thread, the only thing they can
inspect is global state.
Moreover, pretty much the only bits of (local and global) state that
should change during GC are weak pointers and GC statistics. These
things should also change _only_ during GC, so after-hooks can easily
remember their old values and use those to generate the statistics.
Either I am missing something or before-hooks aren't really necessary
if the user has access to the GC statistics he needs.
> It seems to me that a general-purpose hook (even one that's documented
> as "handle with care") would be preferrable to trying to directly
> provide more GC statistics.
Dunno, really. I don't think the amount of statistics that we'd need
to give is overwhelming, but maybe there are funky uses for before-hooks
that I am not seeing.
One possibility would be to just keep *before-gc-hooks* and
*after-gc-hooks* in the current thread, both marked "use with care",
while ensuring that user-code never runs in a dead thread. Then add
safe & sane *gc-hooks* and put them in the (future) housekeeping
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."