[ Not ignoring point 1 or 4, just nothing to say about them. ]
On Thu, Jan 27, 2005 at 10:37:34AM +0900, GOTO Masanori wrote:
>
> (2) Most architectures do not support NPTL currently. Debian
> glibc-2.3.2.ds1-20 supports NPTL on i386, amd64, ia64 and s390.
> So your package is available on only four architectures.
>
> (We have plan to add NPTL support for alpha, ppc and ppc64 in the
> next glibc update. However, currently NPTL is not supported even
> in upstream cvs on arm (EABI update), mips (tls register
> discussion), hppa (Hurrah Carlos O'Donell), m68k (slow speed is
> everytime big problem in computer history). It's sure that hurd
> and *bsd are out of scope with NPTL.)
Regarding the BSD ports and NPTL: absolutely out of scope, but also mostly
irrelevant; the threading libraries on all variants I know of are more
or less fully POSIX compliant (as NPTL is, and LinuxThreads is not) and
capable of handling N threads for values of N that scale well (again, which
NPTL can do, and LinuxThreads cannot).
Or, in other words, any package that builds on a BSD and uses POSIX
threading (which means 'uses threading at all' on a BSD, generally) will be
just fine, despite the absence of NPTL.
Or, in short, the sane way to write POSIX threading is to #ifdef the
LinuxThreads as a special case (that you'd generally like to get rid of :),
not to special-case NPTL. This does not, of course, change the necessity of
supporting and detecting LinuxThreads vs. NPTL on the 11 released Debian
ports, since they're all Linux and only some of them have NPTL (as you
bring up above).
Of course, it's fairly simple to check uname on those and skip the check as
irrelevant on known-sane BSD systems (I can't comment on Hurd threading,
having never touched it).
> (3) NPTL is POSIX thread library - I wonder why your package has to
> depend on NPTL. It's sure there're a lot of incapability to
> handle the whole POSIX threading requirement with linuxthreads -
> but it has basic features to use pthread. Depending on the
> specific implementation is not good idea, IMHO. Martin, I would
> like to know why such requirement is needed.
Speaking from direct experience (as in, writing applications running
hundreds of threads handling thousands of transactions per second 24/7):
any 'serious' (high load, high thread count environment) attempt to
use POSIX threading semantics on LinuxThreads, or to rely on certain
fundamental points of POSIX threading (like, say, signal handling) is prone
to fundamental breakage. Not just incidental, but "melt down your system
with processor load" levels.
Databases, for various reasons involving certain design patterns that work
well for them when you can count on sane threading, tend to be extremely
good at triggering this...
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature