Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcvax!ukc!its63b!simon2 From: simon2@its63b.ed.ac.uk (ECSC68 S Brown CS) Newsgroups: comp.unix.questions Subject: Re: SHL LAYERS Message-ID: <213@its63b.ed.ac.uk> Date: Wed, 21-Jan-87 12:04:39 EST Article-I.D.: its63b.213 Posted: Wed Jan 21 12:04:39 1987 Date-Received: Thu, 22-Jan-87 04:47:25 EST References: <1324@cadovax.UUCP> <5528@brl-smoke.ARPA> <380@oblio.UUCP> Reply-To: simon2@its63b.ed.ac.uk (ECSC68 S Brown CS) Organization: I.T. School, Univ. of Edinburgh, U.K. Lines: 97 In article <380@oblio.UUCP> monte@oblio.UUCP (Monte Pickard) writes: >In article <5528@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >> In article <1324@cadovax.UUCP> mitchell@cadovax.UUCP (Mitchell Lerner) writes: >> >Anybody used shl layers? How is it as a user interface? Can I do most >> >of the things that I can do under Berkeley's job control with shl layers? >> >> "shl" can do most of the things you probably use 4BSD job control for, Not true, if you really mean "shl" here, rather than "sxt devices". >> ... > >Good try Doug, but shl (shell layers) is a very poor excuse for job >control under 4.2. This is closer to the truth... - if you actually mean "shl", again. > >Monte Pickard - Counterpoint Computers And now for my own random thoughts on the matter: Actually, to compare the utility program "shl" with the concept of "job control" is not a very clever thing to do. More meaningful would be to compare the SysV implementation of "job layers" (sxt devices) in "shl" with the implementation of "job control" in "csh" or "ksh". I will agree that shl does not stand up to much comparison here. However... if the low-level stuff is compared, then the sysV job-control is not really so bad: it is possible to implement something that looks almost like Berkeley job-control by switching contexts between various sxt devices. Advantages of the sysV approach: o It is "job i/o control" rather than "job cpu control", which seems a "cleaner" way to do things. It is only necessary to suspend a process if it is trying to read or write to your terminal - you don't care whether its running or stopped (in the cpu sense) if its just number-crunching, or doing file i/o. One of the nice consequences of this is that suspending a process (by typing ^Z, or whatever your `swtch' characters is set to...) will not actually "stop" that process until it wants to do i/o. So you don't have to put it in the background if you want it to keep running. o There is no reason why programs should not be aware that they have been stopped/restarted, because the job-control shell could send them signals to tell them about this [perhaps using the user-definable signals SIGUSR1 and SIGUSR2]. I only send a signal when a job is restarted, 'cos this is the useful one (though it is quite possible to do both - if you aren't using the signals for something else, of course: it does tend to monopolize these signals for its own use [argument for there being a lot more user-definable signals!]). In fact, lots of BSD job-control code in programs can be used almost unchanged, if its within "#ifdef SIGCONT"'s, and SIGCONT is defined as SIGUSR[12] in . o Plus all the positive remarks about things that can also be done under BSD. Disadvantages: o There is a limit to how many jobs may be running simultaneously in a single "job group". This limit is in fact 8, which is far too small (and since the shell will almost certainly be using on of the 8, that leaves only 7). This is a direct consequence of implementing it with special devices in the way it's done. I suppose it could have been done with a smaller number of more-intelligent devices, which would increase the number to something more intelligent. o There is a limit to how many "job control groups" there may be active at any one time. This is 16, which is not really enough either. Actually, to get back to how its implemented again, the real "physical" limit imposed is the product of groups times groupsize (16 x 8, as its implemented). This is obviously cretinous. o "Shl" is a pathetic implementation of this. o The "terminal name" is different for each process (and different for the shell, in turn), which can confuse programs that use /etc/utmp for fetching terminal names. (getlogin() doesn't work too well, either). This is hacked in shl by modifying utmp whenever the "current layer" is changed. o Lots of the supporting stuff is very badly done. Like "setpgrp()", for example. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Simon Brown Department of Computer Science University of Edinburgh, Scotland, UK. ...!{seismo,decvax}!mcvax!ukc!cstvax[!its63b]!simon