GC safety and return values
Tom Lord
(22 Dec 2003 20:58 UTC)
|
Re: GC safety and return values
Jim Blandy
(22 Dec 2003 21:26 UTC)
|
Re: GC safety and return values Tom Lord (22 Dec 2003 21:47 UTC)
|
Re: GC safety and return values
tb@xxxxxx
(22 Dec 2003 22:27 UTC)
|
Re: GC safety and return values
Jim Blandy
(22 Dec 2003 22:28 UTC)
|
Re: GC safety and return values Tom Lord 22 Dec 2003 22:10 UTC
> From: Jim Blandy <xxxxxx@redhat.com> >> For example: >> x = SCHEME_CONS (SCHEME_REAL_PART (a), SCHEME_REAL_PART (b)); >> >> although a very natural seeming C statement, is incorrect code. [....] >> For starters, I would like to see all return values passed via >> output parameters so that one would have to write: >> SCHEME_REAL_PART (&tmp1, a); >> SCHEME_REAL_PART (&tmp2, b); >> SCHEME_CONS (&x, tmp1, tmp2); > This is one area where having explicitly-freed reference objects, as > in the JNI, actually works better than the GC_PROTECT approach. With > references, the first expression is perfectly fine --- assuming > SCHEME_REAL_PART always returns a local reference. 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 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. -t