On-line software version change using state transfer between processes

Annotation: [by Steven Richman] Gupta and Jalote take a rather different approach to on-the-fly upgrades. Instead of modifying a running process, they suspend the process and copy it to a new, upgraded process. The copy process has a new code segment that reflects the update, and data and stack segments that are duplicated from the old processes (with pointers modified as necessary). A runtime library contains special versions of the open and close system calls that allow open file descriptors to be transfered to the new processes. The system only considers an upgrade valid if none of the modified functions are being executed at the time the update occurs. This is enforced by having the application run as a child process of an upgrader process: the upgrader process uses the ptrace debugging system call to monitor the application's stack. This quiescence requirement precludes the update of long-lived functions that are often or always on the stack, such as top level functions or event processing loops. Gupta and Jalote posit that these sorts of functions generally can be made static, with the ``real work'' delegated to shorter-lived functions. It is not obvious that this is true, and their quiescence requirement may prove onerous in many applications. The programmer is allowed to specify a single state transformer function that is executed when the rest of the upgrade is complete.

BibTeX entry:

@article{gupta93online,
   author = {Deepak Gupta and Pankaj Jalote},
   title = {On-line software version change using state transfer between
	processes},
   journal = {Software Practice and Experience},
   volume = {23},
   number = {9},
   pages = {949--964},
   month = sep,
   year = {1993}
}