On Sun, Aug 27, 2000 at 09:55:50PM -0700, Marty Fouts wrote:
> 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
My proposal does not require any more of a distinction than is already
in the spec: the spec repeatedly warns that thread ids are not necessarily
visible outside the process and the notion of a thread within a process
is all over the spec.
e.g.
|This standard includes system interfaces to support applications with
|requirements for multiple flows of control, called
|threads, within a process.
And one of the problems that motivated this discussion was the POSIX
requirement that a signal sent to a "multithreaded process" be sent to
some thread that has enabled that signal or, if no thread is willing
to accept it, the signal must be marked pending and then
delivered to the first thread that enables that signal. When
threads are processes it's a pain to implement this.
> 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.
But some things are specified in grotesque detail -- eg. this signal
delivery mechanism. Or consider
pthread_cancel and the elaborate set of cancellation states. Or pthread_join,
a relic from the days when Modula and CSP were considered serious
programming languages.
> 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.
I'm generally in favor of POSIX, but the spec does wander into pet-theories
too much.
> If you want a description of the one-true-path, you have to go to research
> communities :)
What I want is a spec that says: here is the standard API and a coherent
set of expected semantics that allow users to write portable programs.
Such a spec might easily say: if you mix threads with async I/O you
are in trouble, if you use process signals as IPC to threads you are
in trouble, ...
POSIX does do that enough to make it usable -- invaluable, but not enough
to make me happy.
>
> 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/
-- --------------------------------------------------------- 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