[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]
GL3.2 Version 4.1 for AIX: Programming Concepts

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:

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.


[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]