UNIX processes interact with the operating system, with other processes,
memory, files, devices, and other resources. This means that there is a
significant amount of location dependent state associated with each process;
file descriptors, IPC connections, device locks, etc. In a Unix context, a
process image consists of:
- text, data, and stack segments, and auxiliary kernel data structures.
- open files for the process along with current pointers and modes.
- the state of its controlling terminal and any data in the terminal
queues.
- any other device specific information.
This state information must be migrated with the process and translated as
required in order to ensure that it is valid in the new environment.
Unfortunately, this is a far from trivial task.
- The state information must in general be considered to be dispersed
throughout the process.
- It is not in general possible to decide what is state information and
what not; for example, UNIX file descriptors are simply integers and may be
stored anywhere in memory.
- Processes interact with the kernel through system calls. Most Unix
system calls are either atomic or idempotent or both. No special
handling is necessary for such calls; however, certain calls are stateful, and
the kernel table information must be reconstructed after the migration. If the
migration system is external to the kernel, then this information must be
accessed by using /dev/kmem and/or system calls like ptrace.
- Information about processes may be held in device drivers. In systems
with runtime loadable device drivers neither the kernel nor the process can
know where that information is.
- It is not generally possible to maintain the same process id when a
process migrates from one node to another. This means that the behaviour of
anything which utilises the process id (<#2609#> e.g.<#2609#> in a file name) will be
undefined after migration.
- The behaviour of processes which execute a Unix fork, then wait for
their children is not defined if the process is migrated. On migration, the
process ceases to be the parent of its children and hence waiting for them has
no meaning.
As a consequence of these difficulties almost all Unix process migrations
schemes require quite severe limitations on the processes which can be migrated
(although there is no way of checking compliance). To be migratable, processes
should not:
- Perform I/O on non-NFS files.
- Spawn subprocesses.
- Utilise their pid or any other location-specific information.
- Utilise pipes or sockets.
As a general mechanism then, the last restriction alone suggests that Unix
process migration is not practicable in a general distributed system composed
of communicating entities. In general, migrating an entire distributed
system of application modules which shares state with the underlying
system of communication support (kernel protocols) is close to
impossible.