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.
Graphics Administration Guide for HP-UX 10.20
To Next Page
Loading...
Need help?
General