> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

    > 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
calls.

    > 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.

-t