> > No. Bill's suggestion is NOT antithesis.
> 
> Yes, it is.  When you talk about `kernel threads' in this context,
> you're talking about Mach kernel threads, which simply don't exist in
> NetBSD, and would literally take *years* to implement the way they're
> done in Mach.  This is not practical.

I don't think so, although I agree that it is better to make our 
thread lighter than current state.

> Macrokernels like NetBSD just don't work this way.  If you were, e.g.,
> to create what we'll call a `NetBSD kernel thread' every time a
> process/thread blocks, the overhead would be so amazingly bad that the
> thread implementation would be useless.

As I wrote previous mail, this overhead could be workarounded by
thread buffering. So this is not problem.

> > Perhaps Uresh Vahalia's "UNIX Internals" might confuse your memory.
> > 4th paragraph of section 3.5 in this book describes that
> > 	At any time, a process has exactly one activation
> > 	for each processor assigned to it.
> > But this sentence is wrong!
> > This should be described as follows:
> > 	At any time, a process has exactly one *running* activation
> > 	for each processor assigned to it.
> > I.e. there are more than one activations on each processor, if
> > there are blocked activations.
> 
> Vahalia is primarily describing Solaris/SVR4, and it's my belief that
> Solaris/SVR4 does *not* work this way.  The activation state is saved
> by the thread library and then freed; it does not persist for the
> duration of the block.  In the normal case, a threaded program on
> Solaris has at most one LWP (which corresponds with a `NetBSD kernel
> thread') per processor, and no more.

Hm, now I seem to know where you misunderstood.

Until Solaris 2.5, Solaris's thread implementation works as you
described.
But since Solaris 2.6, the implementation is changed from the above
way to scheduler activations, because scheduler activations is better
about performance than above way.
SGI IRIX and Compaq Tru64 UNIX have been switched to scheduler
activations before Solaris (because of performance reason).

Please note that Vahalia book was published before Solaris 2.6 was
released.
--
soda