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

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

> as it gives you an insane amount of overhead.  It would actually be
> *cheaper* to just have one `kernel thread' per user thread.

The overhead can be descreased by "thread buffering" technique,
i.e. on thread termination, do not deallocate the data structures of
the terminated thread, and hold it for future thread creation.
Implementation of this is not so hard.

> Please read the papers.

Mmm, strange...
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.

In figure 1 of original paper [1], when scheduler activation (A) blocks,
kernel creates new scheduler activation (C) to notify the userlevel
thread scheduler that (A) has been stopped, just like Bill said.
And there are two scheduler activations, (A) which is blocked, and
(C) which is running, in same processor at this time.

Please (re)read the papers.

[1]
Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska and Henry M. Levy.
"Scheduler Activations: Effective Kernel Support for the User-Level 
Management of Parallelism," Proceedings of the Thirteenth Symposium 
on Operating System Principles, Oct. 1991, pp.95-109
	http://www.cs.berkeley.edu/~brewer/cs262/Scheduler.pdf
--
soda