gill (09/01/82)
#R:randvax:-60200:physics:21500001:000:2815 physics!gill Aug 31 21:49:00 1982 I don't know much about PLATO, so I won't try and say why it isn't any good. What I will do is correct a few things you tried to say about UNIX. Ever tried control S (XOFF) on a non-ancient UNIX system? sounds like the STOP key you described. The program doesn't see it. Big deal. I don't think you understand the clist mechanism. No matter what hardware you have, and how fast your terminals are, there will be times when the terminal is in fact incapable of handling data that a program wants to generate. Though we now have faster-than-teletype terminals, many of the newer "smart" terminals can't keep up with constant output. Some send XON/XOFF. Some use external gated clocks. Some just require you to use pad characters. Some just can't be run at high speeds. Oh yeah ... we also have faster than 11/20 processors. In any case, as long as there is this dichotomy, it will be necessary to store the characters until the terminal is ready. Since our present machines do not have infinite storage, a certain limit (HIWAT) was set as to how much storage a particular program might squander from a common pool. Past this point, the program must be suspended (either by busy waiting, or by the more efficient sleep/wakeup mechanism which lets other users run) to make its data output rate equal to that accepted by the terminal. You are incorrect in saying that UNIX processes can't run concurrently with output. The DH11 DMAs its characters directly from the clists. A particular clist chunk may be being output through dma while the program is filling another chunk. In the case of character at a time devices, the device may drain a clist through interrupts while a program is filling it. If a UNIX program is writing characters at the same rate the terminal is accepting them, the process will not get suspended. Of course, doing a single large write is putting characters out at a very high burst rate. To avoid sleep on large writes, one would have to make HIWAT larger than the largest write. Then, the program would only have to ouput at the correct average rate across two successive writes to never get blocked. I believe MERT (written up in the BSTJ) arranged scheduling to take CLIST levels into account, thus coersing programs into having optimum i/o rates. I don't know how the vanilla UNIX scheduler performs in this light, but the sleep/wakeups make it sort of unnecessary (except for input, where a program subject to alot of input data might need to be scheduled more often). In any case, the problem is not nearly as simple as you make it sound. On conventional, small address space uni-processors, it will be very hard to beat clists. They let alot more processes perform effeciently than if each was given its own pre-allocated queue. Gill Pratt ...alice!gill OR gill@mc
obrien (09/04/82)
I've been aware of all the points you mention about clists, etc. for many, many years. I stand by my comments.