SHL LAYERS

[ECSC68 S Brown CS]

In article <380 at oblio.UUCP> monte at oblio.UUCP (Monte Pickard) writes:
>In article <5528 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>> In article <1324 at cadovax.UUCP> mitchell at 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 <signal.h>.

	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