Subject: RE: Kernel Threads (was Floating point in the kernel)
To: 'Guenther Grau' <Guenther.Grau@bk.bosch.de>
From: Calvin Vette (IT- Borders Online) <CVETTE@borders.com>
Date: 09/18/1998 15:52:19
I believe we do have the manpower and more importantly, the talent. The
you mentioned does lend itself to other things as well, including thread
Cluster computing becomes a lot more realistic, as well.
From: Guenther Grau [SMTP:Guenther.Grau@bk.bosch.de]
Sent: Friday, September 18, 1998 3:39 PM
Subject: Re: Floating point in the kernel
John F. Woods wrote:
> But I hope that threads (user threads, anyway) will not be made
> lightweight: if the kernel is aware of user threads and schedules
> (as opposed to threads existing as figments of user processes'
But please don't make it as complex, configurable, flexible and
as the solaris threads. I don't think that we have the manpower to
properly design and implement this, and IMHO it is overkill to have
kernel threads, which are mapped to one or many process threads, and
are bound or not bound to a certain cpu. Flexibility is great, but
when it get so complicated :-)
> then (a) you get non-blocking I/O for "free" (one thread blocking
> doesn't block other threads in that process), and (b) different
> a process can make use of multiple CPUs (OK, so that's more
> a 256 processor KSR machine than in is on a dual-Pentium... ;-) ).
I think even on a dual cpu machine, cpu-intensive tasks will
run quicker if split up in independend tasks.
Now, if we only had SMP and kernel threads already in the tree, the
(NetBSD-) world would be a better place :-)