Re: The taming of the before-gc-hook (was Re: Upcoming 1.3.2 release)

[Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE>]

Mikael Djurfeldt <mdj@thalamus.nada.kth.se> writes:

> Imagine a library which produces objects which use some common
> resource.  When the objects are collected we want them to free their
> use of the resource, j

Hmm.  I think that means that a container object (or a factory object
that produces other objects but that would finally be the same) has
$n$ objects and if this container object is collected it must invalidate
the resource (a file handle for example).

That's exactly what I did yesterday.  The container object is a smob
(an environment) and the observer objects that belong to the container
are smobs, too(*).  Now if the container smob (if it's not a smob,
just wrap a smob around your data) is no longer referenced its free()
method is called and it can invalidate the common resource and the
back-pointer to itself that the observer objects observing this
environment use to access the common resource.  Once the environment
is gone its observers will be collected unless someone still
references it.  But then the observer detects that its container (the
environment) is gone and does nothing.

I think you can either use a functional programming style in which you
don't care much about your data and use guardians or you can use a
object oriented style with methods surrounding and operating on your
pieces of data.  That's where the finit() function that smobs provide
is handy.  When a smob goes away it can easily invalidate the data it
owns.

When you invalidate the smob and all observers in a after-gc hook it
may happen that someone still holds a reference to one of the observers.



Jost

(*) well, an observer is a piece user-data in a smob jacket :>