summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/object_lookups.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'community/gsoc/project_ideas/object_lookups.mdwn')
-rw-r--r--community/gsoc/project_ideas/object_lookups.mdwn29
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 5075f78..88ffc63 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.