Email list hosting service & mailing list manager

Re: GC safety and return values Tom Lord 26 Dec 2003 18:20 UTC

    > From: Michael Sperber <>

    > Having worked a lot on XEmacs GC issues, I disagree.  What makes
    > it suck in (X)Emacs (IMHO) is the fact that there isn't a
    > consistent methodology to using GCPRO, and that developers
    > constantly try to "optimize" the use of it.

Is that mostly to avoid the cost of GC(UN)PRO calls?  That's why I
suggest GCPROtecting "frame" structures that hold an arbitrary number
of variables at once.  This approach also makes it easier to add and
remove variables without having to simultaneously update GC(UN)PRO

    > For the primitives, you just look up whether they can GC or not.
    > That gets slightly more tedious with more primitives, but not
    > significantly so, I'd say.

Whether a primitie can trigger GC isn't something the FFI should speak
about (because, really, GC can happen just about anytime).  Instead,
there should be a small set of primitives which are designated as
"safe for use when the heap is in a possibly inconsistent state" and a
way for FFI-using programs to declare critical sections during which
the heap is horked.

The set of primitives that are critical-section-safe is almost
certainly going to be very small.