generalized suspend wanted

[edhall%rand-unix at sri-unix.UUCP]

From:  Ed_Hall <edhall at rand-unix>

    From:     Doug Gwyn (VLD/VMB) <gwyn at brl-vld>
    To:       Bob Walsh <walsh at bbn-unix>
    cc:       arizona!budd at ucb-vax, Unix-Wizards at 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 at rand-unix
UUCP:           decvax!randvax!edhall