Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <14852@lanl.gov>
Date: 15 Feb 91 20:32:45 GMT
References: <3204@crdos1.crd.ge.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 28

From article <3204@crdos1.crd.ge.COM>, by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr):
> In article <1991Feb14.153747.26911@eagle.lerc.nasa.gov> xxremak@csduts1.UUCP (David A. Remaklus) writes:
> [...]                                They really didn't want to support
> character at a time interrupts for our portable screen editor. Their
> argument was that "it doesn't make good use of the machine." Our reply
> was that we weere not interested in making good use of the machine, we
> were unterested in making good use of the PhD's who use it. And having
> them moving files to a VAX to edit one line, then back to compile, is a
> poor use of them.

Character at a time interrupts are still a poor way of using the
machine.  The same functionality could be provided by polling from the
OS each time it gets control (and, maybe having a timer set so that
the OS got control at least once every 100 milliseconds).  The system
would then do far fewer context switches when interaction was very
busy (most busy Crays give control to the system _far_ more often than
100 ms anyway - and few people can type 10 characters per second - nor
do they expect response to interactive typing any faster than that).

Of course, the timer is just a secondary suggestion.  Your character
can't be processed until your program gets a timeslice - and the
system has to be in control in order to schedule you.  On a busy
Cray, the average (CPU) timeslice is less than a second too.  (The
average memory residence between swaps is less than a minute.)  So,
even without the timer, respomse to your keystroke will, on average,
be as soon as your program next gets control.

J. Giles