Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!ucbcad!nike!sri-spam!rutgers!im4u!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: job control Message-ID: <5932@ut-sally.UUCP> Date: Mon, 6-Oct-86 19:15:47 EDT Article-I.D.: ut-sally.5932 Posted: Mon Oct 6 19:15:47 1986 Date-Received: Tue, 7-Oct-86 03:43:00 EDT Organization: IEEE 1003 Portable Operating System for Computer Environments Committee Lines: 272 Keywords: POSIX Appendix C Approved: jsq@sally.utexas.edu From: pyramid!utzoo!henry@sally.utexas.edu (Henry Spencer) Date: Sat, 4 Oct 86 03:03:30 PDT After some activity back when the Unix standard was with /usr/group, I've "gone dormant" on standardization work through lack of time. I haven't even seen most of the P1003 stuff. However, I understand that there is a proposal to incorporate Berklix-like "job control" into P1003. Given the interest in getting some new topics into mod.std.unix, I'm submitting the following. It's a slightly touched-up version of a paper Ian Darwin and I submitted to the /usr/group standards effort, arguing strongly that neither 4BSD "job control" nor SysV "shell layers" should be incorporated into a standard. Since I haven't seen the detailed P1003 proposal, it's possible that some of this is out of date, but on the whole I think it's of interest nonetheless. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry [ Perhaps whoever has the original online copy of the current P1003 proposal could submit it? That would probably be worthwhile even if it had to be broken into several articles for space reasons. -mod ] Comments on Terminal I/O, Specifically `Job Control' Henry Spencer University of Toronto utzoo!henry Ian Darwin University of Toronto utcsstat!ian `Job Control', What It's Really About There is no longer any argument that it is desirable to permit orderly user interaction with multiple processes. Unfortunately, a whole generation of Unix users has had their view of this concept warped by the dreadful way it was implemented by Berkeley. And AT&T, in its recent attempt to address the problem, has taken the easy way out instead of doing it right. The basic concept involved here is multiplexing, not `job control' or process suspension. The ideal is something like the environment on the Bell Labs Blit, where multiple processes run simultaneously in multiple windows, and the user can switch his attention and his interaction from one to another at will. There is a popular misconception that doing this *requires* a Blit or a similar highly-intelligent terminal; this is simply not true. Window-based multiplexed interaction is harder to do when the terminal is dumb, but even the Blit is not actually writing things into several windows *simultaneously*: it just looks that way because of the high-speed multiplex- ing involved. There is no intrinsic reason why this multiplexing cannot be done at the other end of the communications line when the terminal is incapa- ble of doing it. The multiplexing can be done in the kernel (albeit at considerable cost in added kernel complexity) or in a user process (given suitable interprocess communication). In either case, the fundamental structure is quite simple: a central `manager' coordinates terminal i/o to and from `client' processes, each of which has total control of its own "virtual terminal". The manager's job is simulating multiple virtual terminals on a single real terminal, by routing input to the appropriate process and placing output in the appropriate area of the screen. - 2 - The basic characteristics of such a multiplexing system are that each process has what looks (to it) like a private terminal, and that all i/o to and from the user is centrally supervised. This is precisely analogous to file i/o under Unix: simultaneous independent activity by multiple processes, coordinated by a central manager which multiplexes physical resources so as to prevent interference. The benefits are similar: individual processes neither know nor care about the multiplexing, and useful high-level abstractions can be implemented in one central place. Job Control and Layers: Half-Baked Approaches The existing schemes, Berkeley `job control' and AT&T `layers', unfor- tunately are clumsy and incomplete attempts at implementing multiplexed interaction. Neither one makes any provision for simultaneous on-screen activities by more than one process, except for the `cop-out' of permitting multiple processes to intermix their output at random. But there are deeper problems. Both schemes require that *every* *program* which is going to participate in multiplexed interaction must contain code to allow for this possibility! User programs must be prepared to redraw the screen on request, with the requests coming from the kernel in the Berkeley scheme and from the user in the System V.2 scheme. This is an abomination. Not only does this demand specialized code in every user program, but it entirely denies multiplexed interaction to the bulk of Unix programs. The concept of `redraw the screen' is meaningful only for interactive programs with full-screen interfaces. The result of, say, an *egrep*, once replaced on-screen by (say) the editing buffer of a *vi*, is gone for good. Since *egrep* is not an interactive program, it is no longer around to be asked to redraw its output. The heart of the problem is that neither job control nor layers imple- ments the crucial half of a window system: centralized management of screen updates. It has long been accepted that multiple processes cannot safely do updates to disks without centralized management and consistency control. The same obviously applies to terminal i/o: orderly simultaneous interaction with multiple processes requires centralized supervision of the interaction. The existing schemes supervise input but not output. It is obvious *why* this deficiency exists: supervising output is the hard part. The idea of switching input from one program to another is reason- ably straightforward. Differences in input handling, such as `cooked' vs. `raw' modes, are relatively minor problems, since the user can be conversing with at most one process at a time. But a CRT terminal permits output from multiple processes to be displayed simultaneously, and coordinating screen updates isn't trivial. Furthermore, there is no agreement on the precise user interface that should be presented for output -- consider, for example, the religious debates over overlapping vs. non-overlapping windows -- and this discourages attempts to provide a single and relatively inflexible central solution. The immense variation in CRT-terminal control sequences puts the icing on the cake. - 3 - Nevertheless, these problems *can* be solved. There are at least three, and probably several more, complete window systems in experimental use. Some of them have performance problems, and most of them are outside the kernel and hence have interprocess-communication problems, but they do work. Standardizing Multiplexed Interaction: A Recommendation As mentioned above, several experimental window systems already exist. (This is quite apart from the `real' window systems on bitmapped workstations, which are also relevant.) Experience with these and other implementations of the same concept will yield a wealth of knowledge on how best to handle this function. It is important that this experimentation, and the adoption of the results that come out of it, not be stifled by further `official endorsement' of incomplete and badly-designed existing schemes. The best approach for P1003 to take on this matter would be to reserve some characters, and some flag bits, for implementations of multiplexed user interfaces, but not to specify any such interface at this time. Such an attempt to specify the interface would be premature, especially when the two approaches under consideration are already known to be grossly-incomplete botches. *Neither Berkeley `job control' nor AT&T `layers' is an adequate imple- mentation of a multiplexed user interface*. *Neither one should be cast in concrete as a standard at this time*. A Retraction Our previous recommendation was that, if multiplexed interaction *must* be standardized, AT&T `layers' would be a better place to start. The layers system, unlike Berkeley job control, does do input multiplexing more-or-less correctly, and hence is essentially upward-compatible with true window sys- tems. It has several desirable characteristics: independent tty state for each layer, suspension/resumption invisible to the processes, a central manager process which is *not* imbedded in a shell, and an implementation that does not have ramifications everywhere. Nevertheless, as discussed above, it doesn't do the hard part: output multiplexing. It also has some annoying implementation limits, which, although they wouldn't necessarily have to propagate into a standard, might well propagate into most early implementations. Its major problem is that it's not clear how to extend it to centralized output management without imbedding said management inside the kernel. We therefore retract our recommendation for standardizing layers as a second choice. The proper course is to standardize nothing, at least until we understand the user-interface issues and the implementation problems better. Specifics A decision not to standardize a multiplexed-interaction scheme notwith- standing, there are a few useful minor things that can be standardized. The *termio* structure probably should have a reserved character or two (or room for same) and a few reserved bits (or room for same) to permit kernel-based - 4 - implementations of multiplexing. In particular, almost any multiplexing scheme using ordinary ASCII termi- nals will need a special character to attract the attention of the multiplex- ing software. Without this, it's very difficult to do things like moving between windows. Reserving space for such a character might be useful; recom- mending a default choice for the character would be very valuable, as it would forestall unnecessary differences between implementations. Control-Z would be plausible. Implementing supervision of multiplexed interaction in user processes is difficult in many existing Unix implementations, minimal implementations of the existing P1003 standard among them. The basic problem is that normal user processes are definitely aware that their output is going to a terminal, the device-independence of Unix i/o notwithstanding. Screen-oriented programs doing *ioctl*s are the biggest problem. A less obvious glitch is that *stdio* adjusts its buffering strategy depending on whether output is to a terminal or not; this is a major nuisance with some existing window systems. Something like the `pseudo-tty' concept would be very useful: an entity which looks like a terminal from one side, but whose behavior is under user-process con- trol from the other side. Some existing systems do implement such things, but the lack of standardization largely prevents use of them in portable programs. Suspending Processes: A Non-Issue Several people have objected to AT&T layers, and similar approaches, on the grounds that `...but 4BSD lets me suspend misbehaving processes...'. This is silly; a process-suspension facility can be very simple if it isn't required to double as a multiplexing system. If it is thought desirable to standardize process suspension, we would suggest the following. Some magic character (control-Y?), when typed as input to a tty/window, suspends all processes attached to that tty/window. The suspension can be, and should be, utterly invisible to the processes involved. This avoids the sticky problem of how to notify the processes without doing incompatible things to the *signal* mechanism. The suspension probably should have a permission requirement analogous to that of signals: if the effective userids of the user and the process don't match, the suspension doesn't hap- pen. This is necessary to prevent major security breaches like suspending *passwd*(1) in the middle of an update to the password file. Note that this suspension facility isn't very useful in the absence of multiplexed interaction -- you can't *do* anything to a suspended process without access to another (real or virtual) terminal -- but the two concepts are nevertheless quite independent. There is no need to confuse them. Volume-Number: Volume 7, Number 30