[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
pointer.
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.
barmar