remove: and GOODS -- identity problems?
Avi Bryant
avi at beta4.com
Tue Jul 6 19:48:37 UTC 2004
On Jul 6, 2004, at 7:16 AM, Adrian Lienhard wrote:
> I chatted with Avi and the simplest workaround we could think of is to
> send rehash when GOODS instantiates a set. That solves the problem but
> it is suboptimal: The rehashing modifies the set which then gets
> written back on each commit. This made the workaround for me unusable
> because too many write conflicts occurred.
I've just put a new version of GOODS on SqueakMap that includes a
KKIdentitySet which doesn't have this problem. You have to give it a
reference to the KKDatabase instance it belongs to when you create it:
set := KKIdentitySet database: myDb.
It then uses this database to find OIDs for any objects you add to it
and use that as the hash code.
Obviously it wouldn't normally work to store an object that referenced
the KKDatabase. To solve this I've added a specialObjects dictionary
to the database that maps objects that have to be external to the db to
negative OIDs. These references get specially tagged when stored in
GOODS to that the GC doesn't try to follow them. For now, the only
specialObject is the KKDatabase instance itself, which has an OID of
-1. The upshot is that if you store references to the KKDatabase
instance, at load time they'll always be resolved to the current
KKDatabase. I mention this mostly because the specialObjects
dictionary might be useful to someone for other unstorable objects.
It would also be useful to build equivalents for BTree and TreeSet, for
storing larger collections.
Avi
More information about the Squeak-dev
mailing list
|