Path: utzoo!attcan!uunet!decwrl!bacchus.pa.dec.com!vixie
From: vixie@wrl.dec.com (Paul Vixie)
Newsgroups: comp.unix.internals
Subject: Re: restarting processes
Message-ID: <1990Sep3.235815.17361@wrl.dec.com>
Date: 3 Sep 90 23:58:15 GMT
References: <24374@adm.BRL.MIL>
Sender: news@wrl.dec.com (News)
Organization: DEC Western Research Lab
Lines: 31

I'd like to do this also.  But if your process has pipes open to other
processes, then those other processes would have to be restarted in the
same state if your process was to be restarted "correctly".  If you had
files open, those same files would have to be there when you restarted,
with the same contents.  If you had a physical device file open, the
results could be confusing (let's say someone else dismounts your tape
and mounts one of their own -- can you get your tape back to the same
"state" it was in when you restart your program?).  And of course, if
you had any network connections open, then all of this stickiness extends
to whatever processes you're talking to on (the) remote machine(s).

This kind of restartability wasn't on the UNIX designers' minds, and the
system call interface has absolutely no architectural support for it.
The thing you're trying to do is usually done at the application layer,
as in "commit" operations in databases, and like that.

If all you really want to do is stop for a backup, then "kill -STOP" will
work (unless you're burdened with some offbrand kernel that doesn't have
job control).  You might also be able to get some mileage out of "undump",
which is subject to the restrictions noted above but it's at least something.

The Sprite operating system has something called "process migration", but
as far as I know a migrating process' locks on system resources are not
released during migration, just lifted up and punched down elsewhere --
this restriction makes everything easy, since all your network connections
and file pointers and so on just stay open while your process moves to
some other CPU.
--
Paul Vixie
DEC Western Research Lab	<vixie@wrl.dec.com>
Palo Alto, California		...!decwrl!vixie