Load control and intelligence in schedulers

[Guy Harris]

> The problem with being smart about giving higher priority to processes
> that do terminal i/o is that all sorts of interesting programs start
> sprouting unnecessary terminal i/o.  I know of one large, hard-crunching
> compiler [name deleted to protect the guilty] which put out a NUL to
> the terminal each time it read a line of source, to keep its priority
> nice and high.  Argh.

This tactic was used on MULTICS; however, MULTICS gave higher priority to
processes blocking on terminal input, not to all processes doing terminal
I/O (so if you just did a lot of writes to the terminal, it didn't help).
What was done there was to interrupt the job; this didn't kill it, it gave
you a subshell *under* the interrupted job.  You then told that subshell
to continue the interrupted job; since this was all taking place in one
process, the interrupted job benefited from the priority boost given to
the subshell which initially blocked reading a command from your terminal.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy