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

> > > > For scheduler activations, a way for the kernel to arrange to call a
> > > > specific userlevel function is needed, as well as passing it
> > > > arguments.
> 
> > Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:
> > > Well, the way to go here is to spawn a new kernel thread for this
> > > purpose, and then have it return into a signal-trampoline-like piece
> > > of userspace code.
> 
> > This is the absolute, complete antithesis of scheduler activations,
> 
> 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.

To review: with the Mach microkernel, all of the actual work is done
by separate server processes.  The microkernel is tuned so that the
entire `kernel' stack state is unwound when a thread blocks (in most
cases), so that only one kernel stack is needed per processor
(usually).  Thus, creating and switching to a new kernel thread is
extremely cheap and can be done at will.

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.

> Scheduler activations (on it's original paper, i.e. [1]) just works
> like Bill suggested.

For a definition of `kernel threads' which don't exist in NetBSD.

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

> Please (re)read the papers.

Been there, done that.  NetBSD is not Mach 3/4.