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.