From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Cc: torvalds@osdl.org Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel From: C H Forsyth In-Reply-To: <1077899988.21772.196.camel@zevon> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 27 Feb 2004 17:32:31 +0000 Topicbox-Message-UUID: 0054cfe2-eacd-11e9-9e20-41e7f4b1d025 >>I said: user mode using it: show me the example! my impression, and it's only that, is that relatively few user mode applications use clone-for-threads at all on Linux, as yet. thus, it's a little unfair, or at least pointless, to ask Torvalds for specific Linux user mode examples since there aren't many generally. (i am curious to know what applications there are that do use it, though.) examples seem few partly because Unix programs aren't typically structured as cooperating threads (however they cooperate). that's partly because the most obviously portable way to do it, pthreads, has several awful or incomplete implementations. you don't know what you're going to get (or rather, you know only too well). (i don't refer here to the pthreads specification, just its implementation in practice, because that's what is relevant here.) for instance, some in the past tried to do it all with coroutines and an internal scheduler that (say) intercepted operations on file descriptors and multiplexed coroutines using select/poll. >>One other detail: as far as I can see, >>your examples all use shared memory as a cheap substitute >>for message passing: why? in practice, you often end up sharing something even for message passing (for instance a Channel or a mailbox if those are your models), unless you meant reading and writing pipe file descriptors, in which case the sharing (if it's a pipe) is tucked away inside the kernel but it's still there. >>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. inferno on linux currently conditions the stack and sp as previously discussed, not least because the place used by the original scheme wasn't any longer visible. that does require machine-specific code to access the sp, although that's in a linux-386-dependent include file. fortunately clone accepts the stack pointer for the new process (although that's machine-specific as to whether it's top or bottom), so there's no need for assembly-language to bounce to the new stack (as there was in FreeBSD for a few years, until they extended the rfork interface).