From mboxrd@z Thu Jan  1 00:00:00 1970
In-Reply-To: <95d43a901ffade2982d28db8d39180b2@collyer.net>
References: <95d43a901ffade2982d28db8d39180b2@collyer.net>
Mime-Version: 1.0 (Apple Message framework v612)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <98DCC07A-6939-11D8-B851-000A95B984D8@mightycheese.com>
Content-Transfer-Encoding: 7bit
Cc: Linus Torvalds <torvalds@osdl.org>
From: Rob Pike <rob@mightycheese.com>
Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel
To: 9fans@cse.psu.edu
Date: Fri, 27 Feb 2004 07:28:30 -0800
Topicbox-Message-UUID: 00020fbe-eacd-11e9-9e20-41e7f4b1d025

> I think we're talking past each other due to different terminologies.
> Linus seems to use `thread' to mean `a process sharing address space
> (other than normal text segment sharing)', whereas in Plan 9, that's
> just a process; some share address space, some don't.  A Plan 9 thread
> is entirely a user-mode creation of the Plan 9 thread library, which
> doesn't implement POSIX threads.

i was speaking using linux's terminology.

 > Having a pointer that sometimes works, and sometimes doesn't, based
on who
 > uses it - that's just crazy talk.

put in those terms, it sounds weird, but it's not.  consider the old u.
area in unix.
that was a piece of address space with the same virtual address in all
processes
but a different content.  the system used the fact that the addresses
aliased
that way.  plan 9's thread model does a similar thing by constructing a
special
storage class for data private to each process.  for instance, one can
have a
variable with the same address in each process, call it tp, that points
to the
thread-specific data, so you can write code like
	printf("my id is %d\n", tp->id);

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

 > The same way it creates any other storage: with mmap() and brk(). You
just
 > malloc the thing, and you pass in the new stack as an argument to the
 > thread creation mechanism (which linux calls "clone()", just to be
 > different).

that wasn't what i was asking.  i was referring to this special storage
class.
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.

ah, i see in later mail that you answered this. there are now pointers
created in the user space (i think) to thread-local storage.  how is it
accessed, that is, how does the user process derive the pointer to it?
this state stuff did not exist when we did the inferno port.

oh, and now i see you answering that later.  it is 'cruft', as you say,
but
it will work; it's the magic address bits hack.  which kernel version
introduced this stuff?  i've heard people say that 2.6 is the first one
with the default thread model being 'efficient' and 'good', but i don't
know the specifics.  i've also heard that they can be retrofitted to
2.4.

i think a big part of my confusion is that my criticisms of linux
threads are
based on an older view of how they worked.  and a big part of the
commentary that started the discussion was incorrect about plan 9
history.  i hope we're on the same page now.

it's interesting you advocate using registers for the magic storage
class.
it's a great trick when you can do it - plan 9 uses it in the kernel on
machines
with lots of registers - but it's not so great on a machine with too few
registers, like the x86.

-rob