Messages in this thread | | | Date | Sun, 27 Aug 2000 20:17:19 -0600 | From | yodaiken@fsmlabs ... | Subject | Re: SCO: "thread creation is about a thousand times faster than |
| |
On Sun, Aug 27, 2000 at 09:50:53PM -0500, Dave McCracken wrote: > 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
What is "broken" about Pthreads is the clumsy interaction between UNIX semantics and threads and it seems to me that this is all due to overdesign and some false assumptions in the threaded programming model that was current 15 years ago. While we do have the benefit of hindsight, the same overdesign continues in POSIX drafts. To note a pet-peeve of mine, the POSIX specification of priority-inheritance embeds a stupid mechanism in what should be a policy specification.
> 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.
I think that POSIX threads is a great specification struggling to dig its way out of the garbage piled on top of it. To take one example, why not simply define signals by: UNIX signals are per-process, thread signals are per-thread? E.g. an implementation will act as if the original exec'd program is the process and does all signal handling. This process may use pthread_kill to pass signals on to threads, but there is no interaction between process masks and thread masks and no interaction between process and thread signals.
> 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.
One of the reasons I like Linux is that nobody has too much reverence for past design decisions. In fact, a famous Australian Linux developer recently described his own code as "20,000 lines of untested crap", but I think that was rather unkind as there are somewhat less than 20,000 lines.
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
- 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/
| |