lkml.org 
[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: 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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.095 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site