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 Lord <lord@xxxxxxx> 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.