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_Hall 

    From:     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