From owner-freebsd-hackers  Tue Oct 24 21:36:30 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA26975
          for hackers-outgoing; Tue, 24 Oct 1995 21:36:30 -0700
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26970
          for <hackers@FreeBSD.ORG>; Tue, 24 Oct 1995 21:36:28 -0700
Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id VAA16988; Tue, 24 Oct 1995 21:34:48 -0700
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199510250434.VAA16988@ref.tfs.com>
Subject: Re: process migration
To: terry@lambert.org (Terry Lambert)
Date: Tue, 24 Oct 1995 21:34:47 -0700 (PDT)
Cc: bugs@ns1.win.net, hackers@FreeBSD.ORG
In-Reply-To: <199510250359.UAA18032@phaeton.artisoft.com> from "Terry Lambert" at Oct 24, 95 08:59:29 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1624      
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> 
> 
> There's also other problems:
> 
> 1)	File as swap store.  The executable file is acting as its own
> 	swap store; this means you must reopen the file (which means
> 	you need its name) and reestablish the flags on the vnode to
> 	orevent writes to it.
write the entire process space including non resident pages..
(implies that shared programs become static )
> 
> 2)	Memory overcommit.  There very well may not be enough swap
> 	to checkpoint the program.
put it out to a file.......
> 
> 3)	Shared libraries.  The shared library mappings must be
> 	restored, probably seperately.
static.. quite possibly this might be used in a specialist environment
(such as what russel is working on,) where shared libs might not be required
in any case)
> 
> 4)	Shared memory, semaphores, etc.
this gets hard,
> 
> 5)	Open file descriptors.
you can only do a single process, file descriptors not open to files
probably are pointed deadfs (as if the other end died)
> 
> 6)	Network listens (recoverable) and network connections (not
> 	recoverable if reliable stream delivery, recoverable for
> 	stateless datagrams).
listens can probably be re-established if you can track them down..
certainly a certain amount of info can be stored on each fd, and a listen
sounds feasible to restart..
> 
> 7)	Mapped files (other than shared libraries).

> 
> 8)	FIFO/pipe/cooperating process recovery.
> 
> This is a non-trivial task.
I guess that's whey they decided to do it :)
> 
> 
> 
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
>