During the M9 freeze there was some discussion [0] about HARMONY-6123 [1].
I've had a look at this issue. I've attached a patch to the above JIRA that attempts to add calls to XLockDisplay/XUnlockDisplay around a single call (XNextEvent) that appeared in the backtrace for this bug. Sadly, it causes a deadlock with one thread waiting with the (new) lock in XNextEvent and another (presumably trying to obtain a lock) in XSendEvent. (Aside: Why does XNextEvent require explicit lock calls when XSendEvent is clearly making them implicitly/internally?) Since XNextEvent is intended to block until an event becomes available *and* is required to hold a display lock, I can't see how this can easily be resolved. Google reveals that some projects solve this by: 1) doing all Xlib calls on a single thread, 2) using XPending and busy wait (loop/sleep) waiting for an event or 3) rewriting to use the new xcb/xcbutil instead of xlib I'm not particularly enthusiastic about any of these - 2 is least effort but horrible. Anyone have any bright ideas or comments? Regards, Mark. [0] http://markmail.org/message/mcngtqjtdphwno3w [1] https://issues.apache.org/jira/browse/HARMONY-6123
