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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST