> Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping
> of kernel threads to user threads. All the kernel threads, and thus
> all the user threads, share the same memory region - including the
> stack region. Their stacks are differentiated solely by different
> values in the stack pointer register. Thus I don't think what you're
> suggesting is possible.
I don't see how fork() semantics can be preserved unless
the stack regions are replicated (copy-on-write) on a fork().
Under ATT and BSD Unix (which is where I did most of
my kernel hacking in the old days) that was the *only*
way to get a new kernel thread, so it was "obvious"
that my proposed hack would work. Linux does have
the clone() function as well, and if LinuxThreads are
implemented in terms of clone(foo, stakptr, CLONE_VM, arg),
you are correct, the proposed scheme would not work
without modification.
One such modification would be to have each newly
cloned thread explicitly allocate and map a 1-page
VM region that is private to the kernel thread, and bound
to a known virtual address that is common to all threads
within the task. That known virtual address would take the
place of the below-the-stack storage location I described
earlier. The same algorithm would apply - one has a globally
known address that maps to different storage per-thread,
which can be used to store the address of the (globally visible)
per-thread information. The set-up is slightly more complicated
and heavyweight than the fork()-based model I suggested,
but one could in principle eliminate one level of indirection
at on the lookups at run-time.
Regards,
Kevin K.
