[166] in Pthreads mailing list archive
Re: An idea for pthreads
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Oct 26 07:04:03 1995
Date: Thu, 26 Oct 1995 06:16:14 -0400
From: Ken Raeburn <raeburn@cygnus.com>
To: Antony Courtney <antony@apocalypse.org>
Cc: ghudson@MIT.EDU, pthreads@MIT.EDU
In-Reply-To: Antony Courtney's message of Wed, 25 Oct 1995 17:31:08 +0200
From: Antony Courtney <antony@apocalypse.org>
Date: Wed, 25 Oct 1995 17:31:08 +0200
>> - there is just one true location for errno, used by all threads
>And how do you expect this to work if you have multiple processors?
I don't, but that's because I don't expect to ever use MIT pthreads on a
multiprocessor. I would argue that people who use multiprocessors tend to
use vendor-supported operating systems on those multiprocessors, and probably
will do so for the foreseeable future.
Except for the folks at MIT working on NetBSD for dual-processor
systems. I know Chris, at least, was supposed to be working on this.
Which brings us to the next question: why is the MIT pthreads project
trying to do *any* bindings for vendor-supported OSs? Why not leave users
who want to use those OSs to pester their vendors for threads support,
leaving you to focus on the platforms that matter for free software? As I
More specifically, they'd have to pester their vendors for threads
support compliant with the final POSIX standard. Otherwise they wind up
conditionalizing their code for "standard" pthreads versus pthreads
draft 4 versus pthreads draft 7 versus Sun LWPs versus Windows NT
threads versus whatever else I haven't run into yet.
And even if the vendor does decide to go with the POSIX standard, how
long will it take them to get there? And get it implemented correctly?
What are applications programmers supposed to do in the meantime --
simply ignore those operating systems? Won't happen. Most of them will
instead ignore threads or hack up their own code to do the same thing,
just not as well.
understand things, the big vendors (SGI, Sun) are damn near having native
pthreads support anyway.
Some already have it, if you don't mind packages based on older drafts
of the POSIX standard, with different interfaces.
Rather than doing vendors' work for them, a much better goal, IMHO, would be
for MIT pthreads to provide a good multithreading story for those OSes that
are cheap or free, and also unsupported (Linux, FreeBSD, etc.).
The vendors still have plenty to do. I doubt Chris et al will work on
kernel threads for any non-free OS, since kernel source is kind of
required for that. And as for doing the vendors' work for them, I'd
rather hand them a working implementation than have them ship me broken
code in an OS release.
Once the vendors have complete support, yes, it might make sense not to
bother. But if you want consistent behavior, and sources to build from
for debugging, the vendors won't help you much there. And Chris has
been talking about adding some extra frills to the MIT code beyond the
basic POSIX requirements. Having those consistently available across
systems would be a win too.
Besides, something will be needed when NetBSD or Linux get ported to
those boxes and you throw away the vendor OS.
...And I'd be willing to bet that most of that market segment (myself
included) don't have (and never plan to have) multiprocessors running their
free (or nearly free) OS.
You might be right. But I've been toying with the idea of getting a
dual-Pentium system myself....
