[175] in Pthreads mailing list archive
Re: errno & multiprocessors (was Re: An idea for pthreads )
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Oct 27 07:03:48 1995
Date: Fri, 27 Oct 1995 06:05:36 -0400
From: Ken Raeburn <raeburn@cygnus.com>
To: pthreads@MIT.EDU
In-Reply-To: Antony Courtney's message of Fri, 27 Oct 1995 00:23:40 +0200
From: Antony Courtney <antony@apocalypse.org>
Date: Fri, 27 Oct 1995 00:23:40 +0200
By the same token, I could ask, if the pthreads group are targetting
multiprocessor support, multiple OSes, and multiple architectures all at
once, instead of just focusing on one or a few platforms, how long will
it take you all to deliver something that provides basic, correct,
well-tested functionality for a single, common, free OS such as Linux?
And what are we programmers who want to develop for such free OSes supposed
to do in the meantime?
The multiprocessor support isn't completely there anyways. It's just
that some design decisions are being made with it in mind as a future
direction. (Though some of the problems being tackled using pthreads
really do want kernel threads to fix them properly.)
Targeting a single OS on a single architecture, even one as popular as
NetBSD and Linux are becoming, still results in a package that's
useless for anyone having to deal with multiple platforms, like yours
truly. And any of the folks at MIT hacking on this stuff.
Most of the configurations currently supported are among the systems
in common use around MIT. Not supporting one of them would mean any
software written using this package simply could not be used on a
significant fraction of the workstations available to the MIT
community. It's a very heterogeneous environment. (Well, I'm still
thinking of only the UNIX subset.) The workstations aren't so
plentiful that anyone wanting one can always get the architecture of
his choice. So to be really useful, any software package should work
on all of the systems.
It does mean that the development is a bit harder. On the other hand,
most of the code is common across all the systems, sometimes with some
conditionalizing on a parameter or two, generally *not*
conditionalizing on every individual target, except for the assembly
support code. It may not work perfectly, but I doubt the vendors'
versions do either. At least its interface is consistent across the
platforms. The types of bugs are probably pretty consistent
too... :-)
Actually, the platform-specific header files are a real pain, and I've
complained at Chris a lot about that. He makes some change to what's
needed in a file, or adds a new file, and some configuration he
doesn't maintain himself is broken until someone fixes the header
files. Or he tries to fix them, but it's not quite right. I keep
thinking that with some spiffier autoconf code, perhaps we could
detect what's needed on each system, and get the right thing to happen
automatically. But two problems stand in the way. First, I'd
probably have to write that autoconf code myself, and second, I'd have
to convince Chris that it was a better way to do it. Right now, I
don't have much time to try to do either one.
I'm merely trying to suggest that it's worth considering making some small
compromises on the long-term goals (like multiprocessor support) for now, in
order to get something that works reliably on the important platforms in the
short-term.
Sure. In fact, I think some compromises probably are being made in
some areas. It's just that in some areas, like in dealing with errno
or stdio, the compromises can be nearly as troublesome as doing it
right, or more so. For errno, you have to deal with thread scheduling
and signal handlers; you save and restore the value on every thread
switch or signal handler invocation, even if errno wasn't actually
used. And relying on shared global storage in a multi-threaded
program is just bad style. Chris might've had some other objections
to the global-errno saving and restoring when I brought it up some
long time ago, but I don't remember any more.
Once you've got kernel threads, the global errno idea is sunk anyways.
So why wait? Why not break the code now? :-)
I do recall Chris talking about some extensions to permit a thread to
use the global errno value at one point. I think it related to
working with libraries you didn't have source for, or something. I
don't remember exactly.
I think I've run out of semi-coherent, useful comments, so I'll stop
now... :-)
Ken
