From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <3e20930a35285fd9eae215ab26f24579@yourdomain.dom> References: <3e20930a35285fd9eae215ab26f24579@yourdomain.dom> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8C23C7BE-68E5-11D8-AEC9-000A95D0C144@mightycheese.com> Content-Transfer-Encoding: 7bit From: Rob Pike Subject: Re: [9fans] Threads: Sewing badges of honor onto a Kernel To: 9fans@cse.psu.edu Date: Thu, 26 Feb 2004 21:26:51 -0800 Topicbox-Message-UUID: fcb0221a-eacc-11e9-9e20-41e7f4b1d025 this is a peculiar distortion of a peculiar episode. the original issue linus objected to, and rather rudely if i remember right, is that if the stacks are distinct, there can be confusing bugs if you pass pointers around that accidentally happen to refer to stack addresses. in practice, we never do this because the thread library makes it all but impossible. however this issue really rankled linus, on the other hand, having a separate piece of address space with different contents is a powerful idea. it's called something like per-thread space, and it's really convenient for many implementation details in threading. but the feature is (or was; i really don't know the situation any more) hard to provide on linux and in fact the clone interface used to be really nasty because the two processes returned from the syscall with two processes sharing the same stack. i understand something has been done to make the code after a clone on linux easier to write, but when linus was dyspeptic about rfork, the linux dance was really tricky. 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. -rob