Re: scheme closures: crash during garbage collection

Re: scheme closures: crash during garbage collection

[Neil Jerram]

[added crosspost to guile-devel]

"gregory benison" <gbenison@gmail.com> writes:

> guile-gnome (up to v. 2.7.98, most recent as of this writing) can
> call scm_gc_unprotect_object() during a scheme garbage collector
> sweep, which is a fatal error in guile-1.8.  In earlier versions
> of guile, it is not a fatal error (but still, I think you're not
> supposed to do it.)

Many thanks for this great analysis.

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.

(I'm not personally familiar with the GC code, but it may be that the
new restriction in 1.8 against doing this was not strongly intended,
but more of a shortcut that was then forgotten.)

That said, your proposed solution would be a good short term
workaround, until we can fix this in the Guile code.

Can people more familiar with the GC code comment on whether this fix
is feasible?

Regards,
      Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Han-Wen Nienhuys]

In article <87odx2ds0o.fsf@ossau.uklinux.net>,
Neil Jerram  <neil@ossau.uklinux.net> wrote:
>> guile-gnome (up to v. 2.7.98, most recent as of this writing) can
>> call scm_gc_unprotect_object() during a scheme garbage collector
>> sweep, which is a fatal error in guile-1.8.  In earlier versions
>> of guile, it is not a fatal error (but still, I think you're not
>> supposed to do it.)
>
>Many thanks for this great analysis.
>
>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.
>
>(I'm not personally familiar with the GC code, but it may be that the
>new restriction in 1.8 against doing this was not strongly intended,
>but more of a shortcut that was then forgotten.)
>
>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




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Marius Vollmer]

hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) writes:

> In article <87odx2ds0o.fsf@ossau.uklinux.net>,
> Neil Jerram  <neil@ossau.uklinux.net> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Neil Jerram]

Marius Vollmer <mvo@zagadka.de> writes:

> hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) writes:
>
>> 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.

So what do you propose, then, for the scenario that Gregory described?

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

If I've understood correctly, this isn't possible in Gregory's
scenario.

(See
http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html
if you didn't see the whole description on guile-gtk-general already.)

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Han-Wen Nienhuys]

In article <87odwyt33x.fsf@ossau.uklinux.net>,
Neil Jerram  <neil@ossau.uklinux.net> wrote:
>If I've understood correctly, this isn't possible in Gregory's
>scenario.
>
>(See
>http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html
>if you didn't see the whole description on guile-gtk-general already.)

I don't understand. The way I read it, Gregory concludes his email
with a solution for his problem. In any event, it's easy to write your
own GC protection scheme, which can have different semantics.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Neil Jerram]

hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) writes:

> In article <87odwyt33x.fsf@ossau.uklinux.net>,
> Neil Jerram  <neil@ossau.uklinux.net> wrote:
>>If I've understood correctly, this isn't possible in Gregory's
>>scenario.
>>
>>(See
>>http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html
>>if you didn't see the whole description on guile-gtk-general already.)
>
> I don't understand. The way I read it, Gregory concludes his email
> with a solution for his problem. In any event, it's easy to write your
> own GC protection scheme, which can have different semantics.

That's true, but surely Guile should be helping developers out here?
Is it hard to allow scm_gc_unprotect_object within GC, or does it
constrain the GC implementation in some undesirable way?

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

>> Guile wants you to integrate your objects with its mark/sweep
>> approach, by providing appropriate smob marking functions, for
>> example.
>
> If I've understood correctly, this isn't possible in Gregory's
> scenario.
>
> (See
> http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html
> if you didn't see the whole description on guile-gtk-general already.)

I think this (and also the problem of reference loops that easily form
over widgets and signal handlers) has been successfully solved in the
guile-gtk bindings of yore: http://www.gnu.org/software/guile-gtk/

Here is the comment describing the wrapping strategy for GObjects:

/* GtkObjects.

   GtkObjects are wrapped with a smob.  The smob of a GtkObject is
   called its proxy.  The proxy and its GtkObject are strongly
   connected; that is, the GtkObject will stay around as long as the
   proxy is referenced from Scheme, and the proxy will not be
   collected as long as the GtkObject is used from outside of Scheme.

   The lifetime of GtkObjects is controlled by a reference count,
   while Scheme objects are managed by a tracing garbage collector
   (mark/sweep).  These two techniques are made to cooperate like
   this: the pointer from the proxy to the GtkObject is reflected in
   the reference count of the GtkObject.  All proxies are kept in a
   list and those that point to GtkObjects with a reference count
   greater than the number of `internal' references are marked during
   the marking phase of the tracing collector.  An internal reference
   is one that goes from a GtkObject with a proxy to another GtkObject
   with a proxy.  We can only find a subset of the true internal
   references (because Gtk does not yet cooperate), but this should be
   good enough.

   By using this combination of tracing and reference counting it is
   possible to break the cycle that is formed by the proxy pointing to
   the GtkObject and the GtkObject pointing back.  It is
   straightforward to extend this to other kind of cycles that might
   occur.  For example, when connecting a Scheme procedure as a signal
   handler, the procedure is very likely to have the GtkObject that it
   is connected to in its environment.  This cycle can be broken by
   including the procedure in the set of Scheme objects that get
   marked when we are tracing GtkObjects with a reference count
   greater than the number of internal references.

   Therefore, each proxy contains a list of `protects' that are marked
   when the proxy itself is marked.  In addition to this, there is
   also a global list of `protects' that is used for Scheme objects
   that are somewhere in Gtk land but not clearly associated with a
   particular GtkObject (like timeout callbacks).

  */


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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Neil Jerram]

Marius Vollmer <mvo@zagadka.de> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>>> Guile wants you to integrate your objects with its mark/sweep
>>> approach, by providing appropriate smob marking functions, for
>>> example.
>>
>> If I've understood correctly, this isn't possible in Gregory's
>> scenario.
>>
>> (See
>> http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html
>> if you didn't see the whole description on guile-gtk-general already.)
>
> I think this (and also the problem of reference loops that easily form
> over widgets and signal handlers) has been successfully solved in the
> guile-gtk bindings of yore: http://www.gnu.org/software/guile-gtk/

Many thanks for this explanation; it looks good.  In principle,
however, I still think this is pretty tricky and so it would be nice
if libguile could offer some help here.  So if it is possible to
generalise this into something not GtkObject-specific, it would be
nice to provide this as a set of libguile library functions.

    Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scheme closures: crash during garbage collection

[Andy Wingo]

Hi,

I'm just now getting around to taking care of this oldie.

On Sat, 2006-07-08 at 18:06 +0300, Marius Vollmer wrote:
> Neil Jerram <neil@ossau.uklinux.net> writes:
> > (See
> > http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html
> > if you didn't see the whole description on guile-gtk-general already.)
[...]
>    By using this combination of tracing and reference counting it is
>    possible to break the cycle that is formed by the proxy pointing to
>    the GtkObject and the GtkObject pointing back.

I'm going to look into what it would take to use mark functions, as
guile-gtk does, instead of rolling our GC protection scheme, as Gregory
did[0]. I'll also look into what python does, as they probably have
things right. Then again, I thought I had things right...

[0] http://lists.gnu.org/archive/html/guile-gtk-general/2006-07/msg00056.html

Cheers,

Andy.
-- 
http://wingolog.org/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel