SIGCHLD and the GRM Daemon

The Graphics Resource Manager Daemon (grmd) is started when the X11 Server is started. In normal operation, a Starbase, hp PEX, or hp-PHIGS application will not start the daemon, and so will not be affected by the SIGCHLD manipulation that occurs as part of that startup (see below). However, if the grmd dies for some reason, the graphics libraries will restart the daemon whenever they need shared memory. This can occur in the following instances:

•During calls to the following Starbase functions: gopen(3g), gclose(3g), enable_events(3g), disable_events(3g), set_signals(3g), and track(3g).

•When hp-PHIGS and hp PEX initialize their output devices.

•When hp-PHIGS input is initialized.

•During calls to glXCreateContext or glXMakeCurrent.

When the grmd is started, the sequence of events is:

1.Set the SIGCHLD action to SIG_DFL, saving the old action.

2.fork(2) and exec(2) an intermediate process, which is the grmd's parent.

3.Call waitpid(2) to wait for the intermediate process to die (after starting the grm daemon).

4.Restore the saved SIGCHLD action.

Between the time that the graphics thread sets the SIGCHLD action to SIG_DFL and restores the saved action, other threads should not change the SIGCHLD action by calls to sigaction(2), sigvector(2), signal(2), sigset(2), or sigwait(2).

The following are possible consequences of such concurrency:

•If the concurrent operation sets the SIGCHLD action to SIG_IGN, the graphics thread could hang.

•If the concurrent operation installs a signal handler for SIGCHLD, that handler may be invoked when the graphics child process dies.

•A call to sigwait might return in response to the death of the graphics child process.

•Any SIGCHLD action concurrently set by the application could be overwritten when the graphics thread restores the saved SIGCHLD action.

Page 117

Graphics Administration Guide for HP-UX 10.20