[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

weak pointers vs temporary hash tables

    Date: Wed, 7 Sep 88 16:05 EDT
    From: Barry Margolin <barmar@Think.COM>

    This discussion we've been having keeps going between temporary hash
    tables and weak pointers, and the implication of the latter discussion
    seemed to be that weak pointers are all you need for temporary hash
    tables.  I'm not sure this is so.

Weak pointers + finalization.

    For temporary hash tables, special measures need to be taken when a weak
    key is GCed.  You can't just set the key slot of the table entry to NIL.
    First of all, it would be nice to also nullify the value slot of an
    entry whose key is GCed, so that the value can be GCed.  This could be
    done by high-level code outside the GC, though.  A more significant
    problem is that most hash table mechanisms need to be able to
    distinguish never-used table entries from deleted table entries.  Also,
    just setting the key field to NIL is no good, because NIL is a valid
    key.  The mechanism for invalidating weak pointers to garbage must
    therefore be cognizant of the high-level structure containing the weak

That's what finalization is for.  The finalization function really has
to be per pointer.  Maybe that means that an explicit form is needed to
dereference a weak-pointer (this would be invisible to users of
temporary hash tables but visible to clients of the subprimitives).
This would probably need to be done anyway, since when you pass an
object referenced through a weak pointer to another function, you
probably want to pass the strong pointer.  

In any case, I don't see why this is a problem.  When you are about to
free an object in a temporary table, you call the finalization function
on it.  The finalization function for this particular weak-pointer is
probably a closure that is closed over the table, and fixes up the
key-field - i.e. it is cognizant of the high-level structure containing
the weak pointer.