[Ecls-list] Finalizer, weak pointer, weak hashes etc.

[Juan Jose Garcia-Ripoll]

On Sun, Apr 27, 2008 at 9:29 PM, Marco Gidde <marco.gidde at tiscali.de> wrote:
>  First of all I think that weak pointers are a useful data structure in
>  their own right - whether they are used or not as a building block for
>  weak hashes is another issue (brought up by me, though).

Sure, I do not argue about this.

> EQ-ness of weak
>  pointers might be a nice property, but of course it has its price:
>  creation of a weak pointer would require scanning the association for
>  the object.

The association itself can be a hash table. Bear in mind that the
garbage collector has two kinds of allocated memory: atomic and
non-atomic. The former is not scanned for pointers. This also relates
to your second question/

> The same would be necessary to retrieve the value from the
>  weak pointer - or the value must be stored in a second place, either
>  inside the pointer (as I did it) or in a reverse association. In either
>  case this second place also has to be invisible to the GC and thus must
>  be handled by GC_general_register_disappearing_link to avoid a dangling
>  pointer. I think that for most use cases of weak pointers this is too
>  much trouble: there will probably be only very few (1, 2 maybe 3?) of
>  them for a given object.

You do not need GC_general_register... to hide a pointer. It suffices
to allocate an object using alloc_atomic() or the equivalent
Boehm-Weiser function. It is then _ECL's_ responsibility to ensure
that the value in the allocated memory is correct. But if we use
finalizers to clean that value ourselves, that's fine.

Another reason why I like the idea of keeping all weak pointers in
some association is that it adapts well to other approaches, such as
inserting our own sweep phase and cleaning the pointers ourselves.
This is just a hypothetical step, but it would be just one line of
code to change the Boehm-Weiser GC to let us do so.

>  Restricting weak hash tables to only weak keys and :TEST 'EQ seems a bit
>  too much. I thought that the usual kinds of weaknesses with the
>  exception of :KEY-OR-VALUE could and should be supported with the full
>  range of test functions working on the key/value, not the weak
>  pointer. But I have to admit I still have no good idea about an
>  efficient and non intrusive implementation.

I had a look at the code and it is possible to make not too intrusive
implementation. The idea is that the notion of weak hash tables is
only used in thre places:
- When extracting the hash key
- When comparing two keys
- When using the key value in things like maphash

The first two are solved by adding three more hash table kinds:
htt_weak_eq, htt_weak_eql, htt_weak_equal, htt_weak_equalp and
changing the associated switch statements. The last one must be
handled by some magic in the si_hash_table_iterate and cl_maphash.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com