diff options
Diffstat (limited to 'community/gsoc/project_ideas/object_lookups.mdwn')
| -rw-r--r-- | community/gsoc/project_ideas/object_lookups.mdwn | 29 |
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. |