Subject: RE: Kernel Threads (was Floating point in the kernel)
To: 'John F. Woods' <jfw@jfwhome.funhouse.com>
From: Calvin Vette (IT- Borders Online) <CVETTE@borders.com>
List: tech-kern
Date: 09/18/1998 15:19:51
The URL below describes a system similar to Sun's lwp, but
asynchronous - a combined kernel/user thread mechanism. Is this along the
lines of what you have in mind?
http://www.is.s.u-tokyo.ac.jp/tech-reports/TR94-02-letter.ps.gz
----------
From: John F. Woods [SMTP:jfw@jfwhome.funhouse.com]
Sent: Friday, September 18, 1998 1:52 PM
To: cgd@netbsd.org
Cc: Jason Thorpe; John F. Woods; tech-kern@netbsd.org
Subject: Re: Floating point in the kernel
> I believe that the notion was that one day that might be 'fixed.'
> But, because there are lots of them and they may switch often, you
> really want kernel thread switching ot be as lightweight as
> possible... So i still think it's unlikely.
And (as I was going to point out in a message eaten by a PPP line
crash)
once you *have* kernel threads, you find that they're the answer to
just
about every kernel programming problem, so (as you said) you want
them to
be as lightweight as possible.
But I hope that threads (user threads, anyway) will not be made
*too*
lightweight: if the kernel is aware of user threads and schedules
them
(as opposed to threads existing as figments of user processes'
imaginations),
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... ;-) ).
That
makes threads heavier-weight than one might like (and, worse, leads
to
people searching for new terms like "fibers" for threads that exist
as
figments of a thread's imagination... ;-) ), but it makes threads
just so
much more useful.