Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!edhall@rand-unix From: edhall%rand-unix@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: Re: generalized suspend wanted Message-ID: <17040@sri-arpa.UUCP> Date: Wed, 7-Mar-84 01:21:00 EST Article-I.D.: sri-arpa.17040 Posted: Wed Mar 7 01:21:00 1984 Date-Received: Sun, 4-Mar-84 03:24:54 EST Lines: 48 From: Ed_HallFrom: Doug Gwyn (VLD/VMB) To: Bob Walsh cc: arizona!budd@ucb-vax, Unix-Wizards@brl-vgr Subject: Re: generalized suspend wanted It's even worse than that. The resources such as files being accessed (especially /etc/passwd, which may be partially buffered in the process's data space) wil in general have changed by the time you restart the process. In other words, this idea has some merit in appropriate cases but is not useful in the general case. Imagine leaving a lock on a database for several days until the program finishes making its update... This is a problem with Berkeley-style job-control as it now stands. Basically, a program that can't be safely stopped should be set up to hold the stop signals during critical sections. As for frequently- changed files, I would suppose that something like an /etc/passwd lookup should also hold stop signals until it reaches a stoppable point. And screen-oriented programs need to reset terminal modes before stopping, and set them again prior to repainting when re- started. Of course, this means that some programs can't be naive about job- control (making it necessary for some programmers not to be naive about job-control). In general, it looks like a generalized suspend would be doable assuming that the shell is made smart enough to store such things as environment and history in a temporary file, and programs which depend upon that environment variables are smart enough to look at them again when restarted from such a suspend; restart would take place from a new login shell with such things as terminal type and so forth set appropriately for the new session, and the rest taken from the temporary file. Kernel mods would be fairly straight- forward, and would essentially involve adding an attach() system call along with new signals for disconnects and restarts. A virtual terminal interface would simplify things enormously for screen programs, but that is more kernel-hacking than most mortals might wish to attempt. The termcap/curses hacking needed is probably easier. -Ed Hall ARPA: edhall@rand-unix UUCP: decvax!randvax!edhall