[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GC safety and return values

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

>>>>> "Tom" == Tom Lord <lord@xxxxxxx> writes:

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

Tom> Is that mostly to avoid the cost of GC(UN)PRO calls?  


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

But (X)Emacs allows this.  It's not about the cost---it's about the
*perceived* cost.

Tom> Whether a primitie can trigger GC isn't something the FFI should speak
Tom> about (because, really, GC can happen just about anytime).

Right; that comes down to just about the same thing.

Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla