From mboxrd@z Thu Jan 1 00:00:00 1970 In-Reply-To: <20040227080632.14232.qmail@g.galapagos.bx.psu.edu> References: <57BB3468-68F4-11D8-B89F-000A95B984D8@mightycheese.com> <20040227080632.14232.qmail@g.galapagos.bx.psu.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <120CA54F-68FD-11D8-B851-000A95B984D8@mightycheese.com> Content-Transfer-Encoding: 7bit Cc: torvalds@osdl.org From: Rob Pike Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel To: 9fans@cse.psu.edu Date: Fri, 27 Feb 2004 00:15:14 -0800 Topicbox-Message-UUID: fdedea2c-eacc-11e9-9e20-41e7f4b1d025 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