From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <0211a9a1c1caaac619da42bdcc0a87af@yourdomain.dom>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Threads: Sewing badges of honor onto a Kernel
From: dbailey27@ameritech.net
In-Reply-To: <8C23C7BE-68E5-11D8-AEC9-000A95D0C144@mightycheese.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Feb 2004 00:37:28 -0500
Topicbox-Message-UUID: fcccc712-eacc-11e9-9e20-41e7f4b1d025


> so it's just a detail, a design choice with advantages and disadvantages
> either way.  win some, lose some. yet somehow our code
> is 'stupid' and linux is 'proper', so i guess the snarkiness endures.

What I am mainly confused about, is... We're talking about user
context threading. In user context threading we've got the abstractions
of a BSS, Data, Text, Stack, (etc in some cases) to maintain a sense
of program-persistant-object-classification. As a coder, we know
and can specify (for the most part) where these "objects" will end
up.

So the question to me is, why would you *want* a unified stack?
The only state in which this might be relevant is threads maintained
in ASM where data is passed back and forth via Stack and manipulated
via Registers. Otherwise, things just don't make much sense. In a
land of higher level languages, this semantic seems irrational.

This is mainly what I love about Plan 9's threading implementation, that
it unifies memory in the heap, and not at the stack. I agree that this
creates a powerful tool not only in efficiency, but also in reliability.

I see Linus' logic as more of a negation of both efficiency and reliability.

I'm not interested in starting a flame war, but I *am* interested in
understanding the logic, because I just can't see it clearly from my
point of view.

Don (north_)