> - whether that mechanism is private mappings or tarot cards matters not,
> so long as it's extremely fast.
I'm not sure if someone mentioned this before but..
It seems to me that in the OS/2 environment this problem was solved by
sacrificing one of the i386 segment registers to a thread-specific value.
Each thread stored a thread id of sorts that could be used to quickly
perform a table lookup and find thread local stuff [it may even have been
that it was a valid segment, don't remember]. There even existed extended
compilers (CSet and HighC) that could generate this inlined code
automatically though some weird pragma.
Obviosly rather Intel specific, but a different sort of solution :>
Jon, looking at the pthread code, I'm not sure it is that horrible - the
pthread interface isn't so hot, but the general concept seems speedy. What
if you were to change pthread so that it set aside the first 4k of the
(aligned) stack pointer for thread-local stuff, then an access to it is
just something like (CURRENT_STACK_FRAME & SOME_MASK) which is probably
a couple instructions on most archs..
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/