Input Line Editing

[Theodore Y. Ts'o]

In article <1112 at ficc.UUCP> peter at ficc.UUCP (Peter da Silva) writes:
>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.

Please note that this is *NOT* what we're running on Athena (although
admittedly you have a chance of getting away with it when you give each
user all of a microvax to play with.)  We have the line editor built
into csh.  I maintain this is the right thing to do, since so few unix
commands are interactive anyway, and the efficiency hit is attrocious.

>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.

It's worse than that.  It does an ioctl every time a key pressed, to
see if you've gone into CBREAK mode.  And tty output also has to go
through the pty pair.

Given that over 90% of the line editing is in the shell (given the
normal set of command-line format unix commands), putting the line
editor in the shell is the right thing to do.  (Assuming you have the
resources to hack the shell, of course.)

						- Ted
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o				mit-eddie!mit-athena!tytso
3 Ames St., Cambridge, MA 02139		tytso at athena.mit.edu
			If it's for real, it isn't!