Browse Prior Art Database

Fork Clone Address Space Implementation on MVS

IP.com Disclosure Number: IPCOM000110381D
Original Publication Date: 1992-Nov-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 5 page(s) / 182K

Publishing Venue

IBM

Related People

Ault, DF: AUTHOR

Abstract

This article describes how the POSIX fork function was implemented as part of the MVS enhancements known as OpenMVS. It covers the creation of the new address space, the propagation of user storage, and the propagation of selected system control structures.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 39% of the total text.

Fork Clone Address Space Implementation on MVS

       This article describes how the POSIX fork function was
implemented as part of the MVS enhancements known as OpenMVS.  It
covers the creation of the new address space, the propagation of user
storage, and the propagation of selected system control structures.

      The major requirements for implementing fork that determined
the choice of design are:
1.   The POSIX 1003.1 standard states that the child process must
have a copy of all the parent's storage at the same virtual address
as the parent and that the parent's and child's storage is unique.
2.   The C Run Time Library (RTL) support needed to provide C
language POSIX interfaces does not support data spaces or access
register mode.

      Requirement 1 could have been addressed by creating a new
address space or by placing all data in a data space.  The data space
option was rejected because of the lack of services available in the
C programming language that deals with data spaces.  So the use of an
MVS address space to satisfy the fork requirements was the only
choice that was POSIX compliant and that still provided the ability
to do useful work in the child process.

      The following is a list of design points that are covered in
the figure:
1.   Capturing the callers' registers and environment so that they
can be completely restored in the child.
2.   Creating a new address space to contain the child process.
3.   Capturing and propagating user storage from the parent process
to the child process.
4.   Capturing and propagating selected system control blocks from
the parent process to the child process.

      There are two methods used in propagating data to the new
address space.  For data that needs to be saved and restored, the
data is copied into a shared data space.  For data that can be copied
as is, a cross memory environment is established that allows the data
to be copied directly from the parent to the child.
Capturing the Environment

      On entry to fork processing, the caller's immediate environment
is verified and captured.  This involves saving the caller's
general-purpose registers, floating-point registers and PSW address.
The caller's access registers are not propagated since data spaces
are not propagated and cross memory environments are not supported
for fork.
Creating New Address Space

      The typical use of fork is from the shell environment.  Each
interactive command executed from the shell results in a fork and an
exec of the command.  This usage means that forks are done frequently
and the use of the address space is of short duration.  Because of
this usage pattern, there is a need to manage a pool of address
spaces.

      The two options that were considered for the address space pool
were APPC and a new address space pool manager that would use ASCRE
(Address Space CREate) to create the address spaces.  The final
decision was to use APPC...