Author: Armin Rigo <[email protected]> Branch: hashtable Changeset: r1550:073ff03f2316 Date: 2015-01-19 18:35 +0100 http://bitbucket.org/pypy/stmgc/changeset/073ff03f2316/
Log: update comments diff --git a/c7/stm/hashtable.c b/c7/stm/hashtable.c --- a/c7/stm/hashtable.c +++ b/c7/stm/hashtable.c @@ -6,8 +6,14 @@ length 2**64. Initially it is full of NULLs. It's obviously implemented as a dictionary in which NULL objects are not needed. -The only operations on a hashtable are reading or writing an object at -a given index. +A real dictionary can be implemented on top of it, by using the index +`hash(key)` in the hashtable, and storing a list of `(key, value)` +pairs at that index (usually only one, unless there is a hash +collision). + +The main operations on a hashtable are reading or writing an object at a +given index. It might support in the future enumerating the indexes of +non-NULL objects. There are two markers for every index (a read and a write marker). This is unlike regular arrays, which have only two markers in total. @@ -18,8 +24,8 @@ First idea: have the hashtable in raw memory, pointing to "entry" objects. The entry objects themselves point to the user-specified -objects, and they have the read/write markers. Every entry object -itself, once created, stays around. It is only removed by the next +objects. The entry objects have the read/write markers. Every entry +object, once created, stays around. It is only removed by the next major GC if it points to NULL and its read/write markers are not set in any currently-running transaction. _______________________________________________ pypy-commit mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-commit
