Tom Lord <xxxxxx@emf.net> writes:
> I understand and appreciate your negative experience with GCPRO in
> emacs; I even agree that an "explicitly-freed reference object"
> approach evades that problem (assuming I infer correctly what you
> mean by that); but....

I explained it in the very first post; it's in the archives.

> I don't think there's anything seriously wrong with the GC_PROTECT
> approach.
>
> Anecodtally: After I forked guile to make systas I made a little
> `lint' program -- it happened not to be for GC issues but for critical
> section demarcations.   It had to do flow analysis similar to what the
> GC issues would take.   It could output "right", "wrong" and "can't be
> sure" for a given function.   Worked like a charm and only took a
> couple of weeks --- very simple-minded flow analysis was sufficient.
>
> GCPRO needs additional tools -- and maybe some code cleanups in Emacs
> (if it hadn't been abandoned) -- but it's not nearly as losing as
> you've made it out to be in the past.

When I described GCPRO as impossible to maintain, I hadn't imagined
the sort of tools you came up with later.  They're a great idea, and
I'm sure they'd help a lot.  Emacs does a lot of "optimization", of
the "I know this object is still referenced, so I'm not going to GCPRO
it" variety --- for example, you GCPRO the variable pointing to the
head of the list, but not the variable that walks along the list's
spine --- which really cries out for some sort of mechanical
verification.

The points I made in the very first post to this SRFI's discussion
list still apply, though --- GCPRO cannot be made to work in
multi-threaded contexts.