Re: Marking smobs for GC

[Russ McManus <russell.mcmanus@gs.com>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Let me drone on a little bit.

I read your discussion with great interest, because I have given this
problem a bit of thought myself in the context of some of the programs
I've written that use guile, and that also have to play nice with
external systems that do their own resource management.

What is interesting to me about your strategy is that it attempts to
share the responsibility for the lifetime of an object between the
Scheme world and the outside world.  Generally I have given up and
given ultimate control of an object's lifetime to one of the two
worlds.  From your description, it sounds like the in-between strategy
can work, with a signficant amount of additional complexity.

GTK widgets are an interesting application for this idea, because
AFAIK, the object's lifetimes really are determined outside of the
Scheme world's domain, because the user can tell the X server to nuke
a particular window at any time.  What does it mean then to have a
live Scheme object representing a GTK widget, if that widget's window
is gone?  At that point, a nonzero reference count still doesn't leave
you with a useful object.  It seems likely that my understanding of
your strategy is incomplete somehow.

If the Scheme world is in charge of the lifetime of a resource, then
life is simple, and the facilities of guile are perfect.  smob mark
and free functions are all you need.

What about the situation when the lifetime of the object is decided
outside of Scheme?  Then it's possible, or even likely that captured
references to these object will become stale at some point.  The
approach I have adopted is stolen from Emacs's buffer handling.  In
Emacs, Lisp buffer objects can point to buffers that have been
destroyed, which are called dead buffers.  The Lisp programmer just
has to be ready to handle this case, which in practice doesn't make
things that much harder or inconvenient.

Of course, there has to be some way to determine whether the resource
is question is dead or alive.  In all of the situations where I've
used this technique, there was some way to receive notifications of an
object's demise, so that the smob structure could be updated to
reflect the object's morbidity.  It may be necessary to track all of
the structures that have been boxed and exported to Scheme for this to
work (usually this can be done with a hash table).

So if I were writing a GTK interface, I would have just used
'widget-live?' or some such.  Maybe this is a loser for some reasons
that I'm missing, but the strategy has worked for me in other
contexts.

-russ

--

Aim for the impossible and you will achieve the improbable.