Subject: Re: What is happening with libpthread???
To: John Birrell <firstname.lastname@example.org>
From: Christian Kuhtz <email@example.com>
Date: 01/20/1997 13:26:02
On Mon, 20 Jan 1997 20:49:28 +1100 (EST), John Birrell <firstname.lastname@example.org> wrote:
> > PS: Yet another reason to run a NetBSD server or NetBSD API compliant
> > server on a Mach mk and built Pthreads on top of Mach C-Threads. 8-]
> Why run NetBSD at all then?
I don't want to start this thread off again, but here's my rationale for
proposing and doing what I am already doing:
I have done Mach mk ports numerous times, and for my it is a fairly
straightforward business, and I believe I have a thorough enough understanding
of Mach internals to be successful at it and come up with something which
will not only work, but perform well.
The Mach mk provides only the most basic functions. Mach-UX relies on a OS
server to provide an API. Or, in case it is Mach-US we're dealing with,
emulation libraries to possibly provide multiple APIs on a per process basis.
However, there are a bunch of goodies that come in the clue bag with this,
and two of them I particularly like: 1.) kernel multithreading and 2.)
It is a fully threaded kernel, and a rock-solid, fast kernel thread API is
available to the user, which can be easily adapted to other threading API's if
so desired, such as POSIX3.1c threads (Pthreads).
Further, I believe, that the fact that Mach mk's are by design meant to be
multiprocessing kernels, makes it very easy to support multiprocessor
environments. To me, it makes more sense to take building blocks meant to
support a particular function, than coax something that isn't meant to provide
multiprocessing to provide multiprocessing.
And since Mach mk's 3.0 and up, even non-shared memory multiprocessor
environments are possible and easily implemented. The APIs themselves have no
clue what it is below their ports to the mk (99.9% of the time).
The whole OS design is much more modular, which makes porting easier as well.
NetBSD has done a tremendous amount of porting work, which is easily
IMHO, NetBSD is a very fine uniprocessor OS. Efficiency for a different
environment might need a different approach than driving a uniprocessor OS to
be a multiprocessor OS. Especially since there are no threads in the current
kernel, IMHO, this job can never been of great efficiency. It'll work, no
doubt, but it won't be the best we can do.
Because the NetBSD server's API will be a superset of the current NetBSD API,
current apps will continue to run at the very least after recompilation.
With a little extra effort, even binary compatibility can be provided.
The argument that Mach mk has more overhead than traditional architectures is
not true per se. Multithreading provides for significant advantages even on
uniprocessor architectures when high I/O demands are to be serviced. For
efficient multiprocessing, threading is a requirement, not an option. And
predominantly userland threading implementations just don't cut it(TM).
That's my story. Comments welcome, flames >/dev/null.
We'll see what happens.
Christian Kuhtz <email@example.com>