klmitch / dbprim Goto Github PK

It would be good to have some sort of options that can be passed to dbprim functions. This would be an API change, as each function would now have an "opts" parameter that could be NULL. The only options for now would be alternate malloc/free, with support for arena-style functions, but I could see this being used in the future for threading (if I can ever figure out how to make that work!)

Right now, if the hash_resize_t callback returns non-zero, that value is returned from ht_resize(). The callback really should be able to inhibit a resize without causing ht_resize() to error out.

The ht_flush() function called ht_remove(), but if AUTOSHRINK is on, ht_remove() could resize the table. This could potentially move some results to buckets that ht_flush() has already processed, leaving items in the hash table. The work-around is obviously to copy the bare minimum entry removal code into ht_flush(), but a better long-term solution could be to split ht_remove() to create an _ht_remove(), which would not contain the logic for resizing the table.

Every time the hash table routines call the hash computation function, the result is immediately passed through % table->ht_modulus and the result stored as the entry's hash. What we should do instead is separate the hash from the bucket index, thus avoiding the need to recompute the hash. This represents both an ABI change (additional he_index field in hash_entry_t) and an API change (previously, the hash algorithm could take the modulus into account, even though it's documented not to), so a version bump would be necessary.

It would be nice to add a priority queue API to the library. This would likely not be intended to be long lived, but there's no reason to eliminate that possibility.

The proposal would be to drop sparse matrices and replace them with a more general graph data structure. This would have to include not just the basic storage, but also some graph algorithms and some support for implementing other algorithms. May have to account for both library-allocated edges (when the caller doesn't care) and caller-allocated edges (when the caller does care).

The hash_entry_t and rb_node_t types contain a database key, but it gets set in routines like ht_add() or rb_add(). This database key really should be a property of the entry/node itself, and changing it should automatically move the entry within the container; so, for instance, ht_move() would become he_setkey().