Re: [9fans] Re: [sources] 20070413: /rc/bin/cpurc.local

["Russ Cox" <rsc@swtch.com>]

> Additionally, we can't assume it starts off. The value is never
> initialized in the C code, so it could be 0, 1, or 382355318. I'm
> assuming that kencc zeroes uninitialized variables in the text, but
> I'm not sure.

This is just not true.  Global variables in C are guaranteed
to be zeroed at program start time.

> Would be nice to know what it does exactly, and why on earth it uses
> /dev/reboot. Note that there is no way to check the state of the
> variable, so one has no clue if one is enabling or disabling
> 'coopsched', whatever it does this interface is clearly far from
> ideal.

True enough.  The toggle was only so it could be turned off
easily if it was a bad idea, and so that the difference could
be measured.  But it turned out to be a good idea and I never
got around to removing the cruft.  The cruft is now gone
from sources.

The code it controlled in the scheduler did the following.
If process A readies process B to run (say, by writing to a pipe
that process B is reading) and gives up the cpu before
its time slice is up, then process B inherits the rest of
process A's time slice.

This makes concurrent programs (like pipelines, but also 
threaded programs that do a lot of context switching)
get something closer to their fair share of the cpu when
there is scheduling contention.  Inspired by L4.

Russ