I'm curious: what assumptions did we have about threads 15 years ago that
turned out to be false? What I recall from attending the P1003.4 meetings
during the first few years of the pthread debate was that there were three
different communities wanting to use 'threads' of control for three
different reasons. The original proposal came from people who were
interested in threads as a programming abstraction for making certain kinds
of programs easier to write; the real time community had a completely
different take, wanting 'extremely lightweight' processes; and the parallel
programming community was looking at various concurrency models.
On the other topic: I took part in interminable debates about the
interaction between threads and various Unix facilities, including the
wrangling over signals. The reality is that (as confirmed later in
discussions with Ritchie,) signals in Un*x are "broken" in that they were
never intended to be used as an IPC mechanism other than at a gross level,
mostly for precise interrupts caused by program failure. The problem was
that they had come to be used as an IPC mechanism and at that time there
were (at least) two competing proposals to 'fix' signals.
In the committee we were stuck trying to resolve a battle between a
community that wanted per-thread signals, a different community that wanted
threads to not (necessarily) be visible outside of the calling process, et
cetera. The answer to your 'why not' was that we deliberately avoided
distinguishing between thread and process precisely to allow both
library-only thread implementations and thread=process implementations. At
a time when 'session' and 'job' were being added to Unix semantics to allow
terminate of related groups of processes (for administration of large
systems) there simply wans't a way we could put together a definition like
yours that wouldn't have caused the community that liked 'the other' model
to vote against the spec.
The *real* problem with posix wasn't overdesign, but rather,
overgeneralization. When you are doing an extention to an OS standard that
doesn't even specify the memory model, it is hard to not overgeneralize.
Standards committes aren't in the business of pointing out the one true
path; they are in the business of describing the least offensive compromise
among existing practicies and pet theories.
If you want a description of the one-true-path, you have to go to research
communities :)
Marty (no longer doing research)
-----Original Message-----
From: yodaiken@fsmlabs.com [mailto:yodaiken@fsmlabs.com]
Sent: Sunday, August 27, 2000 7:17 PM
To: Dave McCracken
Cc: linux-kernel@vger.kernel.org
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/ - 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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST