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

[Rob Pike <rob@mightycheese.com>]

On Feb 27, 2004, at 12:06 AM, Scott Schwartz wrote:

> I suspect Linus isn't subscribed to 9fans, so we'll have to cc him.

sorry about that.

>
> Rob writes:
> | the argument about TLB flush times is interesting.
> |
> | > But it doesn't matter. Regardless, threads should see each others
> | > stacks.
> |
> | and on plan 9, they do.  they just can't see each other's *stack
> | segments*
> | within their own address space.
> |
> | there seems to be confusion on this point.  plan 9's kernel splits
> the
> | stack segment after a fork, but in the normal state, the processes
> run
> | with the sp in shared memory.  the marvelous properties of the
> | same-address-different-contents split stack segment is used only
> | during the fiddly bits of process manipulation and to store
> per-process
> | data.
>
> That sharing is achieved by the thread library, not by the rfork
> system call, though, right?

right. but where it's implemented is in some sense just a detail, as my
other
message, incuded below, implies.

another way of looking at it is that the kernel provide some nice
primitives upon which to build a thread library.  the plan 9 kernel
leaves out a lot of stuff that you're supposed to do in the kernel
for threads, but we were exploring options.

>
> | how does linux store per-process data in user space?
> |
> | -rob

here's my other message, with the cc: this time:


> So in a C/UNIX-like environment, private stacks are wrong. You could
> imagine _other_ environments where they might be valid, but even those
> other environments would not invalidate my points about efficiency and
> simplicity.

as i said before, the stacks are not private.  you're right, that's a
bad thing.
that's why they're not private.

the segment called 'stack' is private, but that's a different thing.
i stress: stack != stack segment.  stack is where your sp is; stack
segment is a figment of the VM system.

i ask again: how does linux create per-thread storage?

the way the plan 9 thread library works is so different from linux's
that they're hard to compare.  program design in the two worlds is
radically different.  so your claim of 'better' is curious to me.  by
'better'
you seem to mean 'faster' and 'cleaner'.  faster at least can be
measured.
you speak with certainty.  have you seen performance comparisons?
i haven't, although it wouldn't surprise me to learn that there are
useful
programs for which linux outperforms plan 9, and vice versa of course.

-rob