IRC.

1 files changed, 29 insertions, 0 deletions

diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn
index 5075f783..88ffc633 100644
--- a/community/gsoc/project_ideas/object_lookups.mdwn
+++ b/community/gsoc/project_ideas/object_lookups.mdwn
@@ -40,3 +40,32 @@ accurate measurements in a system that lacks modern profiling tools would also
 be helpful.
 
 Possible mentors: Richard Braun
+
+
+# IRC, freenode, #hurd, 2013-09-18
+
+In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]].
+
+    <teythoon> braunr: (wrt the gnumach HACK) funny, I was thinking about doind
+      the same for userspace servers, renaming ports to the address of the
+      associated object, saving the need for the hash table...
+    <braunr> teythoon: see
+      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/object_lookups/
+    <braunr> teythoon: my idea is to allow servers to set a label per port,
+      obtained at mesage recv time
+    <braunr> because, yes, looking up an object twice is ridiculous
+    <braunr> you normally still want port names to be close to 0 because it
+      allows some data structure optimizations
+    <teythoon> braunr: yes, I feared that ports should normally be smallish
+      integers and contigious at best
+    <teythoon> braunr: interesting that you say there that libihash suffers
+      from high collision rates
+    <teythoon> I've a theory to why that is, libihash doesn't do any hashing at
+      all
+    <pinotree> there are notes about that in the open_issues section of the
+      wiki
+    <teythoon> but I figured that this is probably ok for port names, as they
+      are small and contigious
+    <neal> braunr: That's called protected payload.
+    <neal> braunr: The idea is that the kernel appends data to the message in
+      flight.