UNIX Futures

[Stanley Friesen]

In article <1524 at wucs.UUCP> nz at wucs.UUCP (Neal Ziring) writes:
>In article <6534 at utzoo.UUCP> henry at 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 at rand-unix.arpa