Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!decwrl!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Input Line Editing
Message-ID: <60787@sun.uucp>
Date: 21 Jul 88 06:51:17 GMT
References: <16541@brl-adm.ARPA> <12184@ism780c.isc.com>
Sender: news@sun.uucp
Lines: 50

> One disadvantage is having the streams tty driver.  There are a couple
> of stream modules ("ntty" and "ld0") that implement network tty
> and line discipline 0, but it's really slow compared to the standard
> tty driver.

I'm curious why this is.  A streams "tty driver" (i.e., a streams module
implementing the standard tty functions) can certainly be faster than a tty
"driver" implemented as a conventional line discipline using the V7/BSD line
discipline interface; in fact, the SunOS 4.0 streams tty driver *is* faster
(requires less CPU time) than the pre-4.0 driver when e.g. doing UUCP at high
speeds.  My suspicion is that this is due to the V7/BSD line discipline
interface requiring one procedure call for every character received; I think
the S5 line discipline interface may be able to pass blocks of characters
across the interface.

> Plus, I think the ld0 module isn't quite as stable as the stardard tty
> driver.  

It hasn't been around as long; what do you expect?  This is not necessarily
caused by streams, although some stuff is more complicated in a streams driver.

> Speed isn't much of a consideration in data comming from the
> tty to the process,

Depends on what you're using the tty for; when a human is typing at it, it's
not vital, but when another computer is pumping data at high speed (e.g., UUCP)
it can be important.

> but the other way around, speed becomes very important.

I don't think "ld0", as it stands, is very smart about output processing.  If
OPOST is clear (and either XCASE or ICANON is also clear - obscure ASR33
feature #101[*]), the driver should spend as little time as possible processing
output; it certainly shouldn't either look at or copy the data if it can
possibly avoid it.  The standard S5 driver bypasses that processing if OPOST is
clear; I don't think "ld0" does so.

The SunOS streams driver bypasses it; it is faster than the pre-4.0 driver on
output, as well as input, in the aforementioned UUCP case.  The 4BSD driver
used prior to 4.0 also tries to blast characters out without processing if it
can, so this can't be chalked off to that.  (It does two copies, though - one
into a buffer on the stack, and one onto the clist.)  If OPOST, or both XCASE
and ICANON are set, it also tries to copy things quickly; it uses a routine
"movtuc" to move characters that aren't processed (except for possibly mapping
lower-case letters to upper-case) until it finds one that needs "special
processing".  (The "movtuc" routine could be done with a VAX "movtuc"
instruction and some glue; see, we didn't even optimize 4.0 for SPARCs - we
optimized it for VAXes! :-) :-) :-) :-) :-) :-) :-) :-))

[*] 101 is a Trademark of Peter Honeyman.