"Marco Maggi":
4. If a garbage collector allows to remove the need for
"scm_remember_upto_here" it must be adopted even if it
makes Guile slower and it raises memory usage a bit (or
more than a bit).
Who cares? I have written thousands and thousands of lines
of guile extensions in C. I have not yet had to use
this. Perhaps it's just dumb luck or something.
While coding GEE I had crashes that I fixed by remembering.
I am probably using it also in places where it is not
required. But I am not able to recognise those places, can
you guess why?
When I developed this:
http://www.notam02.no/arkiv/doc/snd-rt/ , my biggest problem
was all crashes related to garbage collection.
I think I got rid of the last garbage collector-bug in september 2006,
which was related to the ladspa plugin[1] SMOB in the function
rt-compiler.scm/make-ladspa. In that function, the variable "handle"
could be garbage collected during the execution
of the function. The diff for the fix is here:
http://snd.cvs.sourceforge.net/snd/cvs-snd/rt-compiler.scm?r1=1.45&r2=1.46
I think the exampe above shows how insanely complicated things
can get when you manually have to tell guile's garbage collector
what to scan and what not, and I also think it was
a miracle that I eventually spotted the bug. :-)
So in my experience, the current system is very inconvenient, and should
be replaced by a general garbage collector which works also works
for C objects, where this and other related problems wouldn't be an
issue.
[1] ladspa is the linux audio plugin format
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
