From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Wed, 26 Feb 2014 12:32:06 +0100
Subject: IRC.

---
 hurd/libihash.mdwn | 54 +++++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 39 insertions(+), 15 deletions(-)

(limited to 'hurd/libihash.mdwn')

diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn
index be20fa58..57588d55 100644
--- a/hurd/libihash.mdwn
+++ b/hurd/libihash.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013 Free Software
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013, 2014 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -22,23 +22,44 @@ License|/fdl]]."]]"""]]
 
 # Open Issues
 
-  * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]]
+## Collisions
 
-    IRC, freenode, #hurd, 2008/2009
+Viengoos: [[microkernel/viengoos/projects/new_hash_function]].
 
-        <neal> so, we need a new ihash implementation
-        <neal> marcusb: When 80% full, the collision rate is very high.
-        <neal> marcusb: I tested using 512mb / 4096 entries
-        <neal> marcusb: Changing the load factor to 30% resulted in my program
-          running more than an order of magnitude faster.
-        <marcusb> yeah, it shouldn't get so full
-        <marcusb> don't we do an exponential back-off in the array size?
-        <marcusb> of course it's clear we can do much better
-        <marcusb> the ihash algo is very simple
-        <marcusb> I'm not even sure it makes much sense to have a generic
-          library
 
-  * [[community/gsoc/project_ideas/object_lookups]]
+### IRC, freenode, #hurd, 2008/2009
+
+    <neal> so, we need a new ihash implementation
+    <neal> marcusb: When 80% full, the collision rate is very high.
+    <neal> marcusb: I tested using 512mb / 4096 entries
+    <neal> marcusb: Changing the load factor to 30% resulted in my program
+      running more than an order of magnitude faster.
+    <marcusb> yeah, it shouldn't get so full
+    <marcusb> don't we do an exponential back-off in the array size?
+    <marcusb> of course it's clear we can do much better
+    <marcusb> the ihash algo is very simple
+    <marcusb> I'm not even sure it makes much sense to have a generic
+      library
+
+
+## Reader-Writer Locks
+
+### IRC, freenode, #hurd, 2013-12-09
+
+    <teythoon> btw, why don't we use rwlocks for serializing access to our
+      hash tables ?
+    <braunr> teythoon: we definitely could
+    <teythoon> ok
+    <braunr> teythoon: we definitely could use rcu *whistles*
+    <teythoon> should we ?
+    <braunr> i don't know
+    <teythoon> yeah, ofc
+    <braunr> rwlocks have some overhead compared to mutexes
+    <braunr> and our mutexes are already quite expensive
+    <braunr> our condition variables are also not optimized
+
+
+# [[community/gsoc/project_ideas/Object_Lookups]]
 
 
 # Alternatives?
@@ -64,3 +85,6 @@ License|/fdl]]."]]"""]]
   * <http://www.azillionmonkeys.com/qed/hash.html>
 
   * CCAN's htable, idtree
+
+  * Not actually use a hashing data structure; see [[libports]], *Open Issues*,
+    *IRC, freenode, #hurd, 2013-11-14*.
-- 
cgit v1.2.3