|
|
@@ -1,3 +1,6 @@
|
|
|
+Sometime soon, before merge, when this stabilizes:
|
|
|
+* Update the wiki page so it matches reality.
|
|
|
+
|
|
|
Long term:
|
|
|
* Make a mechanism the cache (which does not exist at the time of writing this
|
|
|
note) will be able to notify the NSAS that something has changed (address,
|
|
|
@@ -34,3 +37,10 @@ Long term:
|
|
|
Or recommend that if the result is really needed, that destruction of it
|
|
|
should be considered failure if it wasn't called yet? Make it the default
|
|
|
(eg. signal failure by destruction or call that function from destructor)?
|
|
|
+* Make a zone entry hash table have multiple LRU lists, each one for part of the
|
|
|
+ slots. This will prevent locking contention while still keeping close to
|
|
|
+ the theoretical LRU behaviour (statistically, accesses to each of the part
|
|
|
+ should be as common as to others).
|
|
|
+
|
|
|
+ It might be a good idea to encapsulate the LRUs into the hash table directly
|
|
|
+ (or create a class holding both the hash table and the LRU lists).
|
Michal Vaner