> 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
