No. Xlib and Xt have no mutual exclusion for protecting critical sections. If
your signal handler makes such a call at the wrong time (which might be while
the function you are calling is already executing), it can leave the library
in an inconsistent state. Note that the ANSI C standard points out that
behavior of a signal handler is undefined if the signal handler calls any
function other than signal() itself, so this is not a problem specific to
Xlib and Xt; the POSIX specification mentions other functions which may be
called safely but it may not be assumed that these functions are called by
Xlib or Xt functions.

Setting a global variable is one of the few permitted operations.  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 or by using a custom event loop.

R6 Xt has have support for signal handlers; there is a mechanism to set a
flag in a signal handler, and XtAppNextEvent will notice that the flag has
been set and call the associated callbacks.

Note: the article in The X Journal 1:4 and the example in the first edition
of O'Reilly & Associates' Volume 6 are in error.

[Thanks to Pete Ware (ware@cis.ohio-state.edu) and Donna Converse
(converse@x.org), 5/92]

An alternate solution is to create a pipe and add the read side of the pipe
as an input event with XtAppAddInput; then write a byte to the write side of
the pipe with your signal handler (write is re-entrant). The callback for the
read side of the pipe reads the byte and does the actual processing that you
intended. You may want the byte to be the signal number unless your callback
handles only one kind.

[Thanks to Steve Kappel (stevek@apertus.com)]