henry@utzoo.UUCP (Henry Spencer) (04/08/86)
> > > ...What good does it do to stop > > > a job if I cannot restart it transparently? > You can. If it is prepared to be restarted, i.e. to redraw its screen. This is not what is usually referred to as "transparent", since every program has to know about it. > Since when does EVERY program have to redraw the screen? I stop and start > compiles, makes, news-readers, mail, etc. and none of them do screen refreshes. And therefore you lose their screen output when you restart them. This is a bug, not a feature. Agreed that sometimes redrawing the output would incur unneeded overhead when you don't particularly care about the output, but this is like saying that SVR0 doesn't incur the overhead involved in providing virtual memory -- yes, it's cheaper, but at the cost of not providing a valuable and important capability. > Job control is a helluva lot more than a cheap imitation of a window system. > It is a general method of allowing some user control of system features -- > time sharing and resource sharing. Remember that ^Z is only a character hook > to the rather general SIGTSTP signal! Name three other uses of SIGTSTP. > The ability to stop a process is a > very nice features that is NOT unique to BSD Unix... Agreed, it's not unique to BSD; V8 has it too, in a much cleaner form. Furthermore, it is a feature that has nothing much to do with the rest of job control. It's easy to envision putting it into a window system -- just have a way to stop all processes run from a particular window. Not send a signal to them, but simply freeze them instantly. This does mean you need to have another window so you can do something with them once they are frozen, but that's reasonable enough. > Further, I think window systems are just fine, but they require VERY special > hardware to give acceptable performance. I know people who would dispute this. That aside, though, cheap plastic imitations are usually cheaper than the real thing. You get what you pay for. > Job control frees up system resouces > by allowing processes to be swapped out. Window systems leave processes lying > around, and clutter the system even more with a window managing process! There is no obvious reason why a window system can't let processes be swapped out when they are stopped. Of course, it also gives you the freedom to let them continue running, if that is what you want. As for a window management process, once again you get what you pay for. Surely it is wasteful to have a shell cluttering up the system while you're using an editor, and hence Unix is inferior to a system with the command interpreter wired into the kernel. Right? > The fact that a job can catch or not catch the SIGCONT as it pleases is a very > useful FEATURE! I would be very annoyed if somebody put screen control into > the kernel (!) and forces a screen update (expensive at 1200 baud) every time > I jumped into and out of a process. It's a feature when you don't want to bother with the screen update. It's a bug when you want that screen update but can't get it. Especially when the only way to get it is to modify a tremendous pile of programs that otherwise wouldn't need that complexity. > Don't clutter this group with off-the-cuff opinions and snorts! Both job > control and window systems have their place... That is itself an off-the-cuff opinion, and one that I snort at. :-) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
faustus@cad.UUCP (Wayne A. Christopher) (04/09/86)
In article <6571@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > Since when does EVERY program have to redraw the screen? I stop and start > > compiles, makes, news-readers, mail, etc. and none of them do screen > > refreshes. > > And therefore you lose their screen output when you restart them. This is > a bug, not a feature. Agreed that sometimes redrawing the output would > incur unneeded overhead when you don't particularly care about the output, > but this is like saying that SVR0 doesn't incur the overhead involved in > providing virtual memory -- yes, it's cheaper, but at the cost of not > providing a valuable and important capability. First, if the program isn't prepared to redisplay output anyway, no matter whether or not you have job control it's going to scroll off the screen anyway. You don't gain much... Second, sometimes I will run a program, stop it, cat a file, and then restart the first program and copy information from the file I just catted. Having the program redisplay the screen wouldn't be quite the correct thing... > > Further, I think window systems are just fine, but they require VERY special > > hardware to give acceptable performance. > > I know people who would dispute this. That aside, though, cheap plastic > imitations are usually cheaper than the real thing. You get what you pay for. That's not a convincing argument to people who can't afford suns... > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,decvax,pyramid}!utzoo!henry What are you arguing for? You say that BSD job control is a Bad Thing, and that it is inferior to a window system. Sure, I'd take a workstation without job control over a terminal with job control, but so what? Are you saying that the UNIXes that run on windowing displays should have job control taken out, because it is inelegant and un-UNIXish? Or are you just making fun of people who don't have suns? So far your arguments don't seem to have convinced many people... Wayne
campbell@maynard.UUCP (Larry Campbell) (04/11/86)
> First, if the program isn't prepared to redisplay output anyway, no matter > whether or not you have job control it's going to scroll off the screen > anyway. You don't gain much... > Wayne It doesn't scroll off the screen if you go open another window to do subsequent stuff. Very often I get some useful output on a virtual console, then switch to another virtual console to keep the useful output around for a while. Note that, apart from virtual consoles, my Unix is a straight V7; there isn't a single user-mode program that knows about virtual consoles. They all think they're on a VT100. Note also that there is no requirement that windows be resizable. If they are, programs should be able to find out about it; but a window system where all windows are 24x80 wouldn't be so bad, and would work quite well with existing (unmodified) software. -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
friesen@psivax.UUCP (Stanley Friesen) (04/11/86)
In article <6571@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >Agreed, it's not unique to BSD; V8 has it too, in a much cleaner form. >Furthermore, it is a feature that has nothing much to do with the rest >of job control. It's easy to envision putting it into a window system -- >just have a way to stop all processes run from a particular window. Not >send a signal to them, but simply freeze them instantly. This does mean >you need to have another window so you can do something with them once >they are frozen, but that's reasonable enough. This implementation would violate the spirit of UNIX systems. No process should be placed in a new state from outside, a signal *should* be sent, just in case the process needs to do some sort of clean-up before suspending. Other than insisting on a signal though, I agree that this aproach is nice. But only if it will work on *any* terminal, not just bitmapped terminals! > >> Job control frees up system resouces by allowing processes to be >> swapped out. Window systems leave processes lying >> around, and clutter the system even more with a window managing process! > >There is no obvious reason why a window system can't let processes be >swapped out when they are stopped. Of course, it also gives you the freedom >to let them continue running, if that is what you want. As for a window >management process, once again you get what you pay for. Of course, in fact the system need not even know how a process has been stopped, only that it has. Hmm, another reason for a SIGSTP instead of "instant" stopping, other processes besides the Window Manager may wish to stop processes(such as a debugger). > Surely it is >wasteful to have a shell cluttering up the system while you're using an >editor, and hence Unix is inferior to a system with the command interpreter >wired into the kernel. Right? > I hope this is a :-)! I much prefer a minimal kernel with other functions in ordinary application programs. What I would like to see is the basic hooks for window management in the kernel, such as virtual terminals and a set of signals and primitives for managing them with a Window Shell doing the actual user interface. >> I would be very annoyed if somebody put screen control into >> the kernel (!) and forces a screen update (expensive at 1200 baud) every time >> I jumped into and out of a process. > >It's a feature when you don't want to bother with the screen update. It's >a bug when you want that screen update but can't get it. Especially when >the only way to get it is to modify a tremendous pile of programs that >otherwise wouldn't need that complexity. > What he is saying is that however windowing is implemented it needs to be able to handle "no-redraw" windows for cases where it would be unecessarily expensive to redraw the window when it is reactivated. That is there must be someway of preventing the system from redrawing a screenfull of trivial messages and old commands at 1200 baud over a phone line just because the window containing them has been suspended and restarted! There has been a lot of flaming on this subject, why don't we try to shift to a more constructive discussion. What features are necessary in a windowing system to make it generally useful and acceptable? -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
geoff@desint.UUCP (Geoff Kuenning) (04/13/86)
In article <1097@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > > This implementation would violate the spirit of UNIX systems. > No process should be placed in a new state from outside, a signal > *should* be sent, just in case the process needs to do some sort of > clean-up before suspending. Other than insisting on a signal though, I > agree that this aproach is nice. But only if it will work on *any* > terminal, not just bitmapped terminals! Taking this at face value, given the current scheduler states in the UNIX kernel, we need SIGSWAP, SIGBLOCK, and SIGRUN at an absolute minimum. Sorry, Stanley, but Henry's right and you're wrong. A process should not be informed of scheduling decisions; it's contrary to the very spirit of multiprocessing. Stopping a job is a scheduling decision, nothing more. (O.K., I admit BSD has hung a bunch of other stuff on it. But that's their problem). -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
jqj@gvax.cs.cornell.edu (J Q Johnson) (04/13/86)
In article <279@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: >> ...if the program isn't prepared to redisplay output, no matter whether >> or not you have job control it's going to scroll off the screen anyway. >It doesn't scroll off the screen if you go open another window to do >subsequent stuff. Presumably, any reasonable window system (e.g. the one we run on our Xerox Dandelions) will have a mode of operation in which text is logged locally as it scrolls out of the window. Such text can then be reviewed in the same or a different window, much as one can fumble through the paper that spews out of a hardcopy terminal. Note that this implicit definition of "reasonable" excludes most of the window systems that have been mentioned recently on this list.
guy@sun.uucp (Guy Harris) (04/14/86)
> > No process should be placed in a new state from outside, a signal > > *should* be sent, just in case the process needs to do some sort of > > clean-up before suspending. > > Sorry, Stanley, but Henry's right and you're wrong. A process should not > be informed of scheduling decisions; it's contrary to the very spirit > of multiprocessing. Stopping a job is a scheduling decision, nothing more. The statement "no process should be placed in a new state from outside" is, indeed, ridiculous. However, stopping a job in the BSD job control sense is not a "scheduling decision", any more than terminating it with SIGTERM is. Would you claim that terminating a job is a "scheduling decision" and therefore the process should not be informed that somebody wants it to go away? If you do, I have a job for you cleaning files out of /tmp and /usr/tmp on the machines here.... Besides, you both have it backwards. BSD job control doesn't send a signal to a process because it is being stopped; it stops a process because it received a signal for which the current action is to stop. If you type your stop character at a process which is catching SIGTSTP, your process gets delivered that signal and jumps off into the SIGTSTP handler. That's all. This handler can clean up (just as the SIGTERM handler does) and then stop itself by resetting the handler for SIGTSTP and sending itself a SIGTSTP (just as the SIGTERM handler exits after cleaning up - if it wanted to, it could terminate itself by sending itself a SIGTERM instead). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa
friesen@psivax.UUCP (Stanley Friesen) (04/15/86)
In article <198@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: > >Taking this at face value, given the current scheduler states in the UNIX >kernel, we need SIGSWAP, SIGBLOCK, and SIGRUN at an absolute minimum. > >Sorry, Stanley, but Henry's right and you're wrong. A process should not >be informed of scheduling decisions; it's contrary to the very spirit >of multiprocessing. Stopping a job is a scheduling decision, nothing more. >(O.K., I admit BSD has hung a bunch of other stuff on it. But that's their >problem). And SIGKILL, SIGINT and SIGTERM should also be eliminated because after all terminating a process is "just" a scheduling decision :-) In fact I see a major difference between low-level scheduling operations like swapping and blocking for I/O and higher level scheduling like stopping and terminating jobs. The former are, or should be totally invisible to the user, the latter are often under direct user control, and are invariably plainly visible to the user. I would not want the OS arbitrarily deciding to stop my jobs! And if I have stopped a job I certainly don't want the OS to restsart it on it own! The UNIX philosophy is that the high-level, user-oriented "scheduling" operations are implemented as signals. Whether the signal is catchable or not is a policy decision. personally I feel all un-catchable signals should have a catchable equivalent which is the "usual" or default signal. This allows forced stopping when needed, but allows flexibility where that is desirable. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
dave@garfield.UUCP (04/16/86)
In article <198@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: | Stopping a job is a scheduling decision, nothing more. Not at all. It is informing the process that it's enviroment is going to change - the screen is going to be messed up. Processes which don't care about the screen state can ignore it, processes that do can do something about it. Same with SIGWINCH. dave -- The UUCP: {utcsri,ihnp4,allegra,mcvax}!garfield!dave Mercenary CDNNET: David Janes <dave@garfield.mun.cdn> Programmer "There can only be one!"
jack@boring.uucp (Jack Jansen) (04/17/86)
In article <198@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: > >Taking this at face value, given the current scheduler states in the UNIX >kernel, we need SIGSWAP, SIGBLOCK, and SIGRUN at an absolute minimum. > >Sorry, Stanley, but Henry's right and you're wrong. A process should not >be informed of scheduling decisions; it's contrary to the very spirit >of multiprocessing. Stopping a job is a scheduling decision, nothing more. >(O.K., I admit BSD has hung a bunch of other stuff on it. But that's their >problem). Sorry, Geoff, but I agree with Stanley. There's a *very* big difference between scheduling and stopping jobs: stopping is done by the user. Another difference is on the time-scale. Usually, a job isn't swapped out for too long (except on boring:-), while a stopped job can remain stopped for a long while. I can imagine programs that hold critical locks would like to give them up when they find out they're about to be stopped. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.