Input Line Editing

[Peter da Silva]

In article <9677 at eddie.MIT.EDU>, nessus at wonko.MIT.EDU (Doug Alan) writes:
> There is another way to guarantee that line editing will be uniformly
> supported.  (1) Provide an alternate, and better method.  (See my and
> some other's previous articles on the issue).  (2) Remove line editing
> completely from the kernal, forcing everyone to use the better method.

Here's more or less (modulo problems with my memory) what currently happens
when you hit a key: the lower half driver puts it in its raw queue, and also
processes it and puts it in the cooked queue. It also puts any echoes back
into the output queue for processing (this, by the way, is why writes to
terminal devices aren't always atomic). The total cost of this is two
context switches for entering and leaving the interrupt.

To do it the way you want would basically require all programs to run in
raw mode. This means that now you have: you hit a key, the lower half
driver puts the key in the raw queue. Two context switches. Then your
program wakes up, another context switch. Then it writes the character
to the output stream, two more context switches. Finally your program
goes away to wait for another key. Six context switches, at the minimum.
Plus you execute in user mode. if your program requires swapping or paging
to wake up, it's even worse.

Not only that, but all your programs now have to check to see if they're
in a pipeline and turn this stuff off when they are.

this isn't that much compared to what you Athena jockeys already do, but
it'll kill us poor folks with "mere" vax-class machines and terminals, shared
among a dozen users. Interactive response time will go to hell.
-- 
Peter da Silva  `-_-'  Ferranti International Controls Corporation.
"Have you hugged  U  your wolf today?" (uunet,tness1)!sugar!ficc!peter.