🚀 go-pugleaf

It appears that emacs makes calls to the X client library from witin more than
one signal handler.  This behavior is not supported by the X client code, as it
creates race conditions in the use of client resources which can cause
unrecoverable protocol failures.

In one particular example (with 18.56), the following situation occurred:

(1) Emacs was waiting for input in select() [called by
    wait_reading_process_input()].

(2) A SIGIO arrived, causing the calls to input_available_signal() ->
    XTread_socket() -> internal_socket_read() -> XPending().  XPending is an
    X11 library function.

(3) A SIGALRM arrived, causing the calls to _request_echo() -> echo() ->
    echo_char() -> echo() -> message1() -> update_screen() -> update_begin() ->
    XTupdate_begin() -> CursorToggle() -> XDrawImageString().
    XDrawImageString() is an X11 library function.

At this point our emacs process (on an Alliant FX2800) got into an infinite
loop waiting in XDrawImageString() to take a lock, when that lock had already
been taken in XPending().  Other X11 implementations which do not use locks at
all may experience other symptoms which are harder to analyze.

A standard approach to this problem is provided by the X11 toolkit function
XtAddTimeout() which essentially provides the interval timer functionality in
an X11 safe fashion.  Perhaps similar functionality can be integrated in emacs.

I am interested in comments and suggestions about this problem.

Fred Oliver
oliver@alliant.com