[Ecls-list] Finalizer, weak pointer, weak hashes etc.
marco.gidde at tiscali.de
Sat Apr 26 13:04:02 UTC 2008
"Juan Jose Garcia-Ripoll"
<jjgarcia at users.sourceforge.net> writes:
> On Thu, Apr 24, 2008 at 9:32 PM, Marco Gidde <marco.gidde at tiscali.de> wrote:
>> ... the user can easily turn of the internal object finalization
>> (ie. closing streams) with
> Yes, that is a feature, not a big issue. You should set it to T if you
> want the default finalizing code. But perhaps this semantics is not
> very clear.
The problem IMHO is that user code might do it unintentionally: one
might register a finalizer as some kind of safety net. Later, under
certain conditions, it might be possible to explicitly call the
finalizer and - to avoid the GC overhead - unregister it again. It can't
be expected that users know those types, for which ECL defines its own
finalizers, so to be sure, user code always had to (SET-FINALIZER T) or
check it with GET-FINALIZER before registering its own. This behaviour
should at least be made explicit in the documentation because I had not
expected a finalizer on a freshly created object.
>> Weak pointers on the other hand seem to be quite simple: define a new
>> type with a pointer to cl_object, allocate this cell with malloc_atomic
>> and let GC_general_register_disappearing_link nullify it if appropriate.
>> With these building blocks implementing weak hash tables is still some
>> amount of work, but at least doable.
> My understanding is that this is not efficient and that disappearing
> links should be avoided if possible. I got this feedback from the GC
> mailing list long ago. Now I am not sure what they meant, as having a
> look at the garbage collector's code, they are implemented just like
I didn't take efficiency into account for the moment, just looked what
is there and what might be possible with that. Currently the situation
is just like this: if an application requires weak pointers or hashes,
ECL is not a choice, which is a bit sad.
> However, the real problem is that for scalable weak hashes it is not
> enough to have weak pointers. This is described here:
> and here http://www.haible.de/bruno/papers/cs/weak/WeakDatastructures-presentation.pdf
Thanks for the pointer. I see there is more about weak data structures
than I naively expected, but on the other side: with a level 2
implementation ECL would be in pretty good company. :-)
> Perhaps the simplest solution is, since we do not have control over
> the "sweep" phase in the collector, to go for finalization. One could
> add an "internal" finalization phase as you describe, storing objects
> with weak pointer references in a hash table and updating this table
> and clearing the associated pointers and conses when the object is
This seems to be all we can do with an external garbage collector.
But now I ask myself how to add weak hashes without messing up the code
in hash.d with lots of checks for weak keys/values and letting the user
pay for a feature he/she usually don't want. Still have to think and
maybe start with the simple things, but don't hold your breath - time is
scarce over here :-/
More information about the ecl-devel