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