Re: scheme closures: crash during garbage collection

[Marius Vollmer]

address@hidden (Han-Wen Nienhuys) writes:

> In article <address@hidden>,
> Neil Jerram  <address@hidden> wrote:
>
>>[...]
>>It seems to me, though, that the same kind of situation, leading to
>>wanting to call scm_gc_unprotect_object during GC, is likely to arise
>>in any sufficiently complex application, and hence that we should
>>support this within Guile itself.
>>[...]
>>Can people more familiar with the GC code comment on whether this fix
>>is feasible?
>
> No, MV thinks it's a bad idea, and I agree with him.
>
> See
>  
>   http://thread.gmane.org/gmane.lisp.guile.devel/4117/focus=4160

Yep, and let me elaborate a bit:

The pair scm_gc_protect_object / scm_gc_unprotect_object can be seen
as being Guile's way to implement reference counting for its objects,
maybe analogous to g_object_ref and g_object_unref for glib's
GObjects.  This is true, of course: you can use it to implement
reference counting.  However, it is not a good idea, as Guile offers a
better alternative with its mostly-precise mark/sweep garbage
collector.

Using the protec/unprotect functions for references that change with a
high frequency is quite expensive: Guile objects don't contain a
reference count field, and protecting/unprotecting them is implemented
by putting them in a global list and removing them again.  Also, the
'reference counts' only need to be correct when the GC actually
happens, and keeping them correct all the time is wasteful in that
sense.

Guile wants you to integrate your objects with its mark/sweep
approach, by providing appropriate smob marking functions, for
example.

The function scm_gc_protect_object is intended for long living, global
objects that are referenced from global C variables.  If the global
variable changes often and points to different objects, it might be a
good idea to use scm_gc_register_root instead.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405