From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Threads: Sewing badges of honor onto a Kernel From: dbailey27@ameritech.net In-Reply-To: <5A505668-68E9-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 01:01:48 -0500 Topicbox-Message-UUID: fd34ef7c-eacc-11e9-9e20-41e7f4b1d025 > > I see Linus' logic as more of a negation of both efficiency and > > reliability. > i don't understand his logic. Well, I interpreted his logic that each process, itself, should be the manager of how data is abstracted into each thread. Further, that the kernel should not impose an interface on such userspace processes. When I think in terms of future scalability and dynamic code design, this *seems* to be a good thing. However, over time, we've seen that the lack of a conformed interface has prompted the design of such an interface: pthreads, etc. So, in the end, the necessity for POSIX compliance (or what ever compliance you prefer) is perceived as paramount. Though, this could have been avoided and deemed unnecessary if these kernels had only implemented an interface in the first place. I believe the shortsightedness of not imposing a strict type created too many possibilities. This creates a bigger problem when dealing with libraries imported into a system with no defined interface, and you end up with the desire for one. So, in the end, Plan 9 looks like the better solution. The foresight was there to see a necessity for conformity where all possible permutations of a given set tended to yield outcomes meeting at the same axis: thus an interface. I duno, that's my two cents, anyway. But, that's dependant on me getting Linus' logic correct, which is why he was CC'd. Don (north_)