Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site psivax.UUCP Path: utzoo!linus!decvax!hplabs!sdcrdcf!psivax!friesen From: friesen@psivax.UUCP (Stanley Friesen) Newsgroups: net.unix-wizards Subject: Re: to job control or not to job control (was UNIX Futures) Message-ID: <1097@psivax.UUCP> Date: Fri, 11-Apr-86 14:15:59 EST Article-I.D.: psivax.1097 Posted: Fri Apr 11 14:15:59 1986 Date-Received: Mon, 14-Apr-86 01:46:44 EST References: <67@cstvax.UUCP> <2864@amdahl.UUCP> <137@myab.UUCP> <6534@utzoo.UUCP> <1524@wucs.UUCP> <6571@utzoo.UUCP> Reply-To: friesen@psivax.UUCP (Stanley Friesen) Organization: Pacesetter Systems Inc., Sylmar, CA Lines: 69 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