Subject: Pthreads, libc, and the future
To: None <firstname.lastname@example.org>
From: Michael Graff <email@example.com>
Date: 12/10/1999 15:44:12
So, the ultimate goal is to use scheduler activations (or the like)
for userland/kernel threads. However, in the short-term, I'd like to
get 1.5 shipping with threads.
Along those lines, I'd like to import the code I've been working on,
which is based on MIT pthreads. Yes, I know they're not perfect, but
they work, and they are the easiest to import at this stage.
I'd like to do this ASAP -- this weekend if possible. The issues are:
(1) Not all architectures are currently supported. I have code for
and can test on i386, arm32, while the m68k, alpha, and sparc
code I cannot test even though I have it.
(2) libc should be finished off as a thread-safe library, using
_REENTRANT as the que. To do that, pthread.h (or, more
specifically, the definitions of locks and such) needs to be
present. This means two things:
(a) Changing the threads interface in a major way might
require a libc version bump, or at the least a synchronized
update of libpthread.so and libc.so.
(b) It will tie us down to one specific implementation of
threads. Since it includes our installed pthreads.h file,
another implementation will _not_ work in its place, unless
libc is compiled using its pthread.h file.
Considering the timeline for 1.5, and that bind9 currently _requires_
threads (as do many other packages) I think we need to have pthreads
in 1.5, even if they are not perfect.