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!watmath!clyde!burl!ulysses!bellcore!decvax!hplabs!sdcrdcf!psivax!friesen From: friesen@psivax.UUCP (Stanley Friesen) Newsgroups: net.unix-wizards Subject: Re: UNIX Futures Message-ID: <1090@psivax.UUCP> Date: Mon, 7-Apr-86 11:51:33 EST Article-I.D.: psivax.1090 Posted: Mon Apr 7 11:51:33 1986 Date-Received: Thu, 10-Apr-86 07:16:00 EST References: <67@cstvax.UUCP> <2864@amdahl.UUCP> <137@myab.UUCP> <6534@utzoo.UUCP> <1524@wucs.UUCP> Reply-To: friesen@psivax.UUCP (Stanley Friesen) Organization: Pacesetter Systems Inc., Sylmar, CA Lines: 50 In article <1524@wucs.UUCP> nz@wucs.UUCP (Neal Ziring) writes: >In article <6534@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its > > > >screen. > >A program can catch ^Z, by ``signal(SIGTSTP, stop_handler)''. >Further, the program can also catch the continue -- which lets it redraw the >screen or print a message or change its state or whatever. I have several >programs which do both. > This is only true on BSD systems! On SysV ^Z does NOT SEND A SIGNAL, so there is *nothing* to catch. This is what Henry was complaining about. (At least this is true of all SysV systyems I have ever heard tell of) > >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! The ability to stop a process is a >very nice features that is NOT unique to BSD Unix (TOPS-10 and TOPS-20 had it). However it is not found in SysV UNIX. On ATT UNIX the ^Z simply "disables" terminal I/O to the current process, and the "continue" operation simply re-enables it, there is no SIGSTP signal! > >Further, I think window systems are just fine, but they require VERY special >hardware to give acceptable performance. 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! >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. > >Don't clutter this group with off-the-cuff opinions and snorts! Both job >control and window systems have their place, and they can even work together. > Actually, a properly implemented windowing system should SIGSTP all processes not in active windows. And the window management system is best placed in the kernel where it does require a special process. My main objection to windowing is your last point - it requires to much in the way of special hardware to run correctly. In fact the 1200 Baud over-the-modem problem is *very* serious. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa