Subject: RE: Kernel Threads (was Floating point in the kernel)
To: 'John F. Woods' <firstname.lastname@example.org>
From: Calvin Vette (IT- Borders Online) <CVETTE@borders.com>
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?
From: John F. Woods [SMTP:email@example.com]
Sent: Friday, September 18, 1998 1:52 PM
Cc: Jason Thorpe; John F. Woods; firstname.lastname@example.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
once you *have* kernel threads, you find that they're the answer to
about every kernel programming problem, so (as you said) you want
be as lightweight as possible.
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'
then (a) you get non-blocking I/O for "free" (one thread blocking in
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... ;-) ).
makes threads heavier-weight than one might like (and, worse, leads
people searching for new terms like "fibers" for threads that exist
figments of a thread's imagination... ;-) ), but it makes threads
much more useful.