[165] in Pthreads mailing list archive

home help back first fref pref prev next nref lref last post

Re: An idea for pthreads

daemon@ATHENA.MIT.EDU (Antony Courtney)
Wed Oct 25 20:46:28 1995

To: Greg Hudson <ghudson@MIT.EDU>
Cc: pthreads@MIT.EDU
In-Reply-To: Your message of "Wed, 25 Oct 1995 19:48:41 EDT."
             <9510252348.AA13623@bill-the-cat.MIT.EDU> 
From: Antony Courtney <antony@apocalypse.org>
Date: Wed, 25 Oct 1995 17:31:08 +0200

In message <9510252348.AA13623@bill-the-cat.MIT.EDU>you write:
>>	- 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.

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
understand things, the big vendors (SGI, Sun) are damn near having native
pthreads support anyway.

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.).  

...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.

	-antony

home help back first fref pref prev next nref lref last post