Re: [Bug: 21.4.12] Deadlock with X?
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Greg" == Greg Badros
<greg(a)google.com> writes:
Greg> Every time I can remember it happending I've had gdb-mode
Greg> running in a buffer (though I'm usually not actively
Greg> accessing that buffer). It may be correlated with starting
Greg> a second frame on that same process.
gdb-mode is pretty evil stuff; it runs timers and checks the buffer
rather than parsing the text as it is added. I don't know if this is
necessary anymore, and I doubt that code has been updated in many
years.
Hmmmm... I wonder if anyone wants that task... though it doesn't fix
the root problem, it would address my concern.
Greg> An strace of the running process shows it hanging on a
Greg> select of the unix socket that corresponds to the X server.
Can you get us a stack trace while it's hung?
Presumably with debugging symbols? I can try... it's only every
couple of days that it hangs on me, but I'll make a debug build and
hope for the worst. :-)
Greg> I'm very interested in having this problem fixed, but if
Greg> there's a workaround to break the deadlock, I'd love to hear
Greg> about that, too.
ISTR that there were ways to get XEmacs to wake up out of some
deadlocks. Unfortunately, I can't find the comment/documentation at
the moment. If this is caused by X, maybe moving the mouse and/or
kill -SIGIO might help, per the following comment from event-Xt.c:
I've tried lots of user interactions (such as mouse moves, restarting
the window manager, switching to console and back to X, etc.). I'll
try kill -SIGIO and maybe some other non-terminating signals. The
comment you quote below definitely makes it seem all the more
impressive that this happens as rarely as it does. :-)
Thanks,
Greg
/* #### I'm struggling to understand how the X event loop really works.
Here is the problem:
When widgets get mapped / changed etc the actual display updates
are done asynchronously via X events being processed - this
normally happens when XtAppProcessEvent() gets called. However, if
we are executing lisp code or even doing redisplay we won't
necessarily process X events for a very long time. This has the
effect of widgets only getting updated when XEmacs only goes into
idle, or some other event causes processing of the X event queue.
XtAppProcessEvent can get called from the following places:
emacs_Xt_next_event () - this is normal event processing, almost
any non-X event will take precedence and this means that we
cannot rely on it to do the right thing at the right time for
widget display.
drain_X_queue () - this happens when SIGIO gets tripped,
processing the event queue allows C-g to be checked for. It gets
called from emacs_Xt_event_pending_p ().
In order to solve this I have tried introducing a list primitive -
dispatch-non-command-events - which forces processing of X events
related to display. Unfortunately this has a number of problems,
one is that it is possible for event_stream_event_pending_p to
block for ever if there isn't actually an event. I guess this can
happen if we drop the synthetic event for reason. It also relies on
SIGIO processing which makes things rather fragile.
People have seen behaviour whereby XEmacs blocks until you move the
mouse. This seems to indicate that dispatch-non-command-events is
blocking. It may be that in a SIGIO world forcing SIGIO processing
does the wrong thing.
*/
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.