Xref: utzoo comp.terminals:762 comp.sys.att:3611
Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!mailrus!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.terminals,comp.sys.att
Subject: Re: Info about the AT&T 620 terminal
Message-ID: <8161@brl-smoke.ARPA>
Date: 26 Jun 88 02:47:41 GMT
References: <727@vsi.UUCP> <28765@pyramid.pyramid.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Distribution: comp
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <28765@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
> There are kernel versions [of layers] for System V and 4.3BSD, and a user-
> level version for 4.nBSD using sockets. This latter version is painful, as
> you lose most of the performance gains you get by having the window manager
> in the terminal.

Actually the user-level version uses ptys for host layer I/O (with
multiplexing done by select()).  That is considerably slower than kernel-
level multiplexing, mainly due to the high rate of context switches.
This is apparent when emulating a CRT in a layer, but it is much less
important for typical downloaded interactive front-end processes.
Keith Muller's latest version, which I think is available from AT&T
Teletype, now supports the hostagent feature (i.e. window manipulation
directly from host processes), and that feature does use sockets (this
wouldn't be necessary if ioctls worked right over ptys, as they do on
streams).  I didn't bother with hostagent in the CWI/BRL version, since
there isn't much that depends on it other than a couple of trade-show
demos.

I think Carl is right -- if AT&T knew how to push layers, these terminals
could be rather successful.  I don't know what I would do without one
(and I don't want to find out, at least not until something like Plan 9
is ready to take its place).