282) How can an application be informed of signals?

[Last modified: Mar 96]

Answer:  The answer differs depending on whether you're using X11R5 or X11R6.
For those using X11R6, Ken Lee (http://www.rahul.net/kenton/) writes:  In
X11R6, the Xt library has the new XtAppAddSignal() function. Ken Lee's
December, 1995 *The X Advisor* column has an example:

    http://www.unx.com/DD/advisor/docs/dec95/dec95.klee.shtml

For those using X11R5, these older responses apply:

blackman@hodgkin.med.upenn.edu (David Blackman) writes:

According to comp.windows.x FAQ, you shouldn't make Xt/Xlib calls from a Unix
signal handler:

    "You can work around the problem by setting a flag in the
    interrupt handler and later checking it with a work procedure
    or a timer event which has previously been added."

Kaleb KEITHLEY (fedora.x.org!kaleb) adds:

Xt is not reentrant and it is not safe to call any Xt functions from a signal
handler...  I think [the signaling] technique is covered in the [X] FAQ. On
most POSIX-type systems write(2) is guaranteed to be reentrant and atomic. If
you establish a simple pipe with the pipe(2) system call, and add it as an
XtInput with XtAppAddInput(), then you can write to the pipe in the signal
handler. Xt will notice that input is available and call the input-handler
proc. This technique is inherently better than setting the flag because the
write to the pipe will result in XtAppNextEvent returning immediately without
the latency you observe in using the flag technique.  In R6 you can use the
XtAppAddSignal function.

Ken Sall (ksall@cen.com) adds:  See the "Signal Handling" chapter of "Motif
Programming Manual" by Heller and Ferguson, listed in the BOOKS topic.

Paul Davey (pd@uit.co.uk) adds:  The write and XtAppAddInput input method is
often the best - but be warned it does not work on some SVR3 based Unixes,
where a pipe may not be selected on. SCO Unix exhibits this behaviour so here
the external flag method should be used.