Noriyuki Soda <soda@sra.co.jp> writes:

> > 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.

Only partially.  It does *not* solve the memory usage issues
(currently 8.5k or so per blocked `thread', minimum).  Nor does it
solve more subtle issues (such as bad cache behavior from switching
kernel stacks all the time) that Mach solves.  Solaris does this
partially via `turnstiles'.

> > 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).

I don't have any data on this, so I can't comment on it.