Messages in this thread |  | | Date | Sun, 27 Aug 2000 21:50:53 -0500 (CDT) | From | Dave McCracken <> | Subject | RE: SCO: "thread creation is about a thousand times faster than |
| |
On 28-Aug-2000 Marty Fouts wrote: > With all due respect, as a person who was present for the early evolution of > pthreads, I have to disagree with your assertion of how pthreads came to be. > > Pthreads was designed. The initial proposal that was presented to P1003.4 > was based on a fully functioning multithreaded programming model already in > use (at DEC SRC, IIRC.) Unfortunately, threads and Un*x don't mix without > breaking something. P1003.4 decided to break the threads model in order to > preserve Unix semantics. The design was fine; if there was a problem it was > with the evolution and the compromises needed.
You are in fact right. The original model for Pthreads came from DEC SRC and its Topaz system (written entirely in Modula 3). In fact, the CMU cthreads library was written by a student who spent a summer internship at DEC SRC prior to writing it.
The proposal was submitted to P1003.4 by way of Apollo, where we tried to make it somewhat compatible with Unix semantics (when Garrett Swart of DEC SRC had Unix signals explained to him he was horrified :). The fundamental paradigm we tried to preserve was the concept of a process as the fundamental building block of an application (where a process was defined as an invoked program running in an address space), and threads were simply a way to add some concurrency within that process context. We deliberately avoided the concept that threads have any existence other than as part of that process and its address space.
Linux is clearly starting from an entirely different paradigm in its clone() semantics. While this may well be a better model, I don't think it's fair to call POSIX threads broken and stupid because it wasn't written for the Linux way. Linux's definition of a thread is clearly different than we used when pthreads was designed, but that doesn't make pthreads 'wrong' or 'crap' or 'shit' as Linus is so fond of saying. I'll agree that it makes it difficult to reconcile the two semantics and implement a pthreads library on Linux.
At any rate, I think it should be possible for us all to agree that Linux threads and pthreads have significant differences without resorting to the kind of name-calling I've been seeing in this discussion. Much thought by some very smart developers went into the pthreads design, and how to make it compatible with the Unix semantics we had to start from. The world and the idea of a thread may have evolved beyond what pthreads tried to address, but that doesn't mean it's necessary to heap derision on it.
Dave McCracken dcm@mccr.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |