From 47e4d194dc36adfcfd2577fa4630c9fcded005d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Oct 2013 19:15:06 +0100 Subject: IRC. --- community/gsoc/2013/nlightnfotis.mdwn | 15 ++++++ community/gsoc/project_ideas/object_lookups.mdwn | 63 ++++++++++++++++++++++++ 2 files changed, 78 insertions(+) (limited to 'community') diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn index a9176f51..83e97bc7 100644 --- a/community/gsoc/2013/nlightnfotis.mdwn +++ b/community/gsoc/2013/nlightnfotis.mdwn @@ -3035,3 +3035,18 @@ But not the [[open_issues/libpthread_dlopen]] issue? and we wanna prove that go violates this rule right? That the stack pointer is not pointing at the initial stack yes + + +# IRC, freenode, #hurd, 2013-10-09 + + braunr: The crash is not in the assembly code, but in the called + function from it: + pthread_sigmask (how=2, set=0xf9cac , + oset=oset@entry=0x0) at ./pthread/pt-sigmask.c:29 + 29 struct __pthread *self = _pthread_self (); + Program received signal SIGSEGV, Segmentation fault. + gnu_srs: ok so, same problem as in gcc go + changing the stack pointer prevents libpthread from correctly + fetching thread-specific data (including _pthread_self()) correctly + this will be fixed when threadvards are finally replaced with true + tls diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn index 88ffc633..ca586dea 100644 --- a/community/gsoc/project_ideas/object_lookups.mdwn +++ b/community/gsoc/project_ideas/object_lookups.mdwn @@ -69,3 +69,66 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. braunr: That's called protected payload. braunr: The idea is that the kernel appends data to the message in flight. + + +## IRC, freenode, #hurd, 2013-10-24 + + and, with some effort, getting rid of the hash table lookup by + letting the kernel provide the address of the object (iirc neil knew the + proper term for that) + teythoon: that is a big interface change + how so + optimizing libihash and libpthread should already be a good start + well how do you intend to add this information ? + ok, "big" is overstatement, but still, it's a low level interface + change that would probably break a lot of things + store a pointer in the port structure in gnumach, make that + accessible somehow + yes but how ? + interesting question indeed + my plan for x15 is to make this "label" part of received messages + which means you need to change the format of messages + that is what i call a big change + ok, so we need to provide an update path + but once done, the change to hurd will be minimal, patching + libports should cover most of that + normally yes + so this amounts to messing with gnumach and mig and designing a + clever way to make the update process safe + + libihash is known to show high collision rates + right, libihash + it could use an integer hash function on the keys to distribute + them better + i think that's already what it tries to do + so merely using a better hash algorithm such as murmur should do + the job + or use another data structure altogether + no, it does no hashing of its own on the keys + are you sure ? + well, it uses only prime numbers as sizes, and computes key % + size + well that's hashing .. :) + but this is not really a good hash + yes + isn't that what i said ? + right + ok, I didn't get that ;) + also, the sizes start quite small, 3, 7, 19... + and each time the hash table is grown, all items will have to be + updated + which is why we could consider another data structure + or, for starters, to thin out that list of sizes + my personal preference being radix trees + I assume you have an implementation handy? + yes + cool :D + but good hashing is excellent too + radix trees have their own issues + braunr: http://burtleburtle.net/bob/hash/integer.html + i use thomas wang's hashing function in x15 + or rather, my own personal c utility library, since x15 doesn't + hash anything currently + but murmur is better + we prefer distribution over hashing performances + https://131002.net/siphash/ -- cgit v1.2.3