Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel

[C H Forsyth <forsyth@vitanuova.com>]

>>I said: user mode using it: show me the example!

my impression, and it's only that, is that relatively few user mode
applications use clone-for-threads at all on Linux, as yet.  thus,
it's a little unfair, or at least pointless, to ask Torvalds for
specific Linux user mode examples since there aren't many generally.
(i am curious to know what applications there are that do use it,
though.)

examples seem few partly because Unix programs aren't typically
structured as cooperating threads (however they cooperate).  that's
partly because the most obviously portable way to do it, pthreads, has
several awful or incomplete implementations.  you don't know what
you're going to get (or rather, you know only too well).  (i don't
refer here to the pthreads specification, just its implementation in
practice, because that's what is relevant here.) for instance, some in
the past tried to do it all with coroutines and an internal scheduler
that (say) intercepted operations on file descriptors and multiplexed
coroutines using select/poll.

>>One other detail: as far as I can see,
>>your examples all use shared memory as a cheap substitute
>>for message passing: why?

in practice, you often end up sharing something even for message passing
(for instance a Channel or a mailbox if those are your models), unless you
meant reading and writing pipe file descriptors, in which case the sharing
(if it's a pipe) is tucked away inside the kernel but it's still there.

>>how does a thread identify who it is?  when we were porting inferno to
>>linux (back in 1996; things have likely changed) we resorted to using
>>unused user-visible MMU bits to store enough state to hold on with our
>>fingernails and claw back to private storage. another option we
>>considered was playing with magic address bits in the sp.

inferno on linux currently conditions the stack and sp as previously discussed,
not least because the place used by the original scheme wasn't any longer visible.
that does require machine-specific code to access the sp, although that's
in a linux-386-dependent include file.  fortunately clone accepts the stack
pointer for the new process (although that's machine-specific as to whether
it's top or bottom), so there's no need for assembly-language to bounce
to the new stack (as there was in FreeBSD for a few years, until they extended
the rfork interface).