Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Load control and intelligence in schedulers
Message-ID: <210@rlgvax.UUCP>
Date: Thu, 18-Oct-84 20:13:05 EDT
Article-I.D.: rlgvax.210
Posted: Thu Oct 18 20:13:05 1984
Date-Received: Sat, 20-Oct-84 06:54:14 EDT
References: <151@desint.UUCP> <4451@utzoo.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 18

> 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