Subject: RE: Kernel Threads (was Floating point in the kernel)
To: 'Guenther Grau' <>
From: Calvin Vette (IT- Borders Online) <>
List: tech-kern
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 []
	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
in I/O
	> doesn't block other threads in that process), and (b) different
threads of
	> a process can make use of multiple CPUs (OK, so that's more
interesting on
	> 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 :-)