Multiple Process Management

Special considerations apply to the use of the fork, vfork, and other subroutines and to rendering processes used in conjunction with asynchronous handlers.

Using the fork, execl, execv and Other Subroutines

When using the fork or vfork subroutine with an Enhanced X-Windows, X Toolkit, or AIXwindows application, open a separate display connection (socket) with the XOpenDisplay or XtOpenDisplay subroutines for the forked process. The child process should never use the same display connection as the parent. Display connections are embodied with sockets and sockets are inherited by the child process. Any attempt to have multiple processes writing to the same display connection results in the random interleaving of X protocol packets at the word level. The resulting data written to the socket is generally invalid in the form of undefined X protocol packets that cannot be interpreted by the X server.

The exec and fork subroutines may be used within GL with some restrictions. The GL library manipulates a complex collection of resources. State information is stored in many places: in global (non-exported) variables in the process .data segment; in the X server; in the kernel, as part of the process table; and in the graphics hardware. Children created with the fork subroutine inherit (duplicate copies of) some, but not all of this state information. For example, the fork subroutine does not cause the X server to treat the child process as if it were a new client. In fact, the X server is ignorant of the fact that a fork has taken place. Similarly, the exec routine will overlay the old process image (in particular, wiping out values stored in global variables), but does not reset state contained in the X server or the kernel. (For example, the exec routine does not automatically close files or sockets.)

Current Restrictions

The following restrictions apply to the use of the exec and fork subroutines within a GL application:

• If the exec subroutine is used alone (that is, not immediately preceded by a call to the fork subroutine), and the new process image or any future overlays need to use GL, then the GL gexit subroutine must be called before the exec subroutine. This is required to reset process attributes; if this is not done, GL initialization performed by the new process image will be unsuccessful.
• If the fork subroutine is used alone (that is, not immediately followed by the exec subroutine) then the child process must not attempt to make any additional GL subroutine calls. Drawing by the child process may hang the graphics adapter or the X server, or may cause unpredictable results and place the system in an unpredictable state.

  In particular, the child process should not call the gexit subroutine. Because of a known implementation problem, the gexit subroutine adversely affects the parent process and the GL subroutine call in the child process.

• If the fork subroutine is used alone (that is, without a trailing exec subroutine) and both the child and the parent processes use GL, then the gexit subroutine must be called before the fork subroutine.
• If the fork subroutine is followed by an exec subroutine, the procedures for gracefully resetting the system depend on whether the exec subroutine occurs in the parent or in the child.

  If the exec subroutine is performed in the parent, then a gexit subroutine must precede the exec subroutine.

  If the exec subroutine is performed by the child, then calling the gexit routine can be avoided, but at a risk. Failing to call the gexit subroutine leaves connections and shared memory segments open; this will prevent a process from performing more than nine consecutive forks in a row.

• For programs that end normally (for example, by using the exit subroutine), the gexit subroutine should be called first. In some circumstances, failure to do so can leave a process in the zombie state. Zombies are most likely to occur if the exiting process has child processes that are using GL subroutine calls.

Using Signals and Other Asynchronous Event Systems

GL is not designed to support rendering in a re-entrant fashion from within the same process. In particular, GL rendering from asynchronous handlers, such as signal handlers, is not recommended.

All GL rendering routines are interruptable; they do not mask any signals. GL rendering routines are particularly vulnerable when communicating with the graphics adapter. Adapter commands may be many words in length but must arrive in atomic units; adapter commands with embedded miscellaneous text or symbols may hang the adapter. If a GL routine is interrupted while writing to the adapter, and the interrupting routine also writes to the adapter, the resulting adapter command is embedded in the previously started data stream, thus corrupting it.

If the application performs rendering from within a signal handler, then the application must protect itself. This can be accomplished by masking all relevant signals before beginning rendering and unmasking them after completion. The application must mask all occurrences of rendering, whether within the signal handler or within the main program. Failure to do so risks corruption of the data stream and a hang of the graphic adapter.