John F. Woods wrote:
> 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),

But please don't make it as complex, configurable, flexible and
complicated
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
which
are bound or not bound to a certain cpu. Flexibility is great, but not
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... ;-) ).  That

I think even on a dual cpu machine, cpu-intensive tasks will definitely 
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 :-)

  Guenther