[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC safety and return values
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> 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.