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