summaryrefslogtreecommitdiff
path: root/community
diff options
context:
space:
mode:
Diffstat (limited to 'community')
-rw-r--r--community/gsoc/2013/nlightnfotis.mdwn15
-rw-r--r--community/gsoc/project_ideas/object_lookups.mdwn63
2 files changed, 78 insertions, 0 deletions
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?
<nlightnfotis> and we wanna prove that go violates this rule right? That
the stack pointer is not pointing at the initial stack
<braunr> yes
+
+
+# IRC, freenode, #hurd, 2013-10-09
+
+ <gnu_srs> braunr: The crash is not in the assembly code, but in the called
+ function from it:
+ <gnu_srs> pthread_sigmask (how=2, set=0xf9cac <server_block_set>,
+ oset=oset@entry=0x0) at ./pthread/pt-sigmask.c:29
+ <gnu_srs> 29 struct __pthread *self = _pthread_self ();
+ <gnu_srs> Program received signal SIGSEGV, Segmentation fault.
+ <braunr> gnu_srs: ok so, same problem as in gcc go
+ <braunr> changing the stack pointer prevents libpthread from correctly
+ fetching thread-specific data (including _pthread_self()) correctly
+ <braunr> 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"]].
<neal> braunr: That's called protected payload.
<neal> braunr: The idea is that the kernel appends data to the message in
flight.
+
+
+## IRC, freenode, #hurd, 2013-10-24
+
+ <teythoon> 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)
+ <braunr> teythoon: that is a big interface change
+ <teythoon> how so
+ <braunr> optimizing libihash and libpthread should already be a good start
+ <braunr> well how do you intend to add this information ?
+ <braunr> ok, "big" is overstatement, but still, it's a low level interface
+ change that would probably break a lot of things
+ <teythoon> store a pointer in the port structure in gnumach, make that
+ accessible somehow
+ <braunr> yes but how ?
+ <teythoon> interesting question indeed
+ <braunr> my plan for x15 is to make this "label" part of received messages
+ <braunr> which means you need to change the format of messages
+ <braunr> that is what i call a big change
+ <teythoon> ok, so we need to provide an update path
+ <teythoon> but once done, the change to hurd will be minimal, patching
+ libports should cover most of that
+ <braunr> normally yes
+ <teythoon> so this amounts to messing with gnumach and mig and designing a
+ clever way to make the update process safe
+
+ <braunr> libihash is known to show high collision rates
+ <teythoon> right, libihash
+ <teythoon> it could use an integer hash function on the keys to distribute
+ them better
+ <braunr> i think that's already what it tries to do
+ <braunr> so merely using a better hash algorithm such as murmur should do
+ the job
+ <braunr> or use another data structure altogether
+ <teythoon> no, it does no hashing of its own on the keys
+ <braunr> are you sure ?
+ <teythoon> well, it uses only prime numbers as sizes, and computes key %
+ size
+ <braunr> well that's hashing .. :)
+ <teythoon> but this is not really a good hash
+ <braunr> yes
+ <braunr> isn't that what i said ?
+ <teythoon> right
+ <teythoon> ok, I didn't get that ;)
+ <teythoon> also, the sizes start quite small, 3, 7, 19...
+ <teythoon> and each time the hash table is grown, all items will have to be
+ updated
+ <braunr> which is why we could consider another data structure
+ <teythoon> or, for starters, to thin out that list of sizes
+ <braunr> my personal preference being radix trees
+ <teythoon> I assume you have an implementation handy?
+ <braunr> yes
+ <teythoon> cool :D
+ <braunr> but good hashing is excellent too
+ <braunr> radix trees have their own issues
+ <teythoon> braunr: http://burtleburtle.net/bob/hash/integer.html
+ <braunr> i use thomas wang's hashing function in x15
+ <braunr> or rather, my own personal c utility library, since x15 doesn't
+ hash anything currently
+ <braunr> but murmur is better
+ <braunr> we prefer distribution over hashing performances
+ <braunr> https://131002.net/siphash/