On 28-Aug-2000 yodaiken@fsmlabs.com wrote:
> 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.
Ok, I'll grant you that some parts of it were crap, and some crap was added in
later drafts. I'll admit I've lost touch with the details that've been tacked
on since about Draft 4 or so.
I'll also admit signals were always a mess. They never fit very well with
pthreads, and we pretty much punted in the early drafts. I added sigwait() to
the original draft as a way an application could direct all its signal handling
to a single synchronous 'signal handler' thread, but it never addressed the
larger question of how to make signals and threads play together.
> 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.
All of POSIX was a good example of what 'design by committee' really means,
especially when various members of those committees worked for competing
companies with their own agendas. But on the whole I think we came up with a
decent basic design for what it was, as someone earlier put it... 'thread as
a component of a process' as opposed to Linux's 'thread as a process'.
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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST