Special considerations apply to the use of the fork, vfork, and other subroutines and to rendering processes used in conjunction with asynchronous handlers.
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.)
The following restrictions apply to the use of the exec and fork subroutines within a GL application:
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 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.
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.