The documentation for this family of functions very clearly says not to call into xlib in your predicate function, but historically single threaded apps could get away with it just fine, and now that we've forced thread-safety on the world such apps will now deadlock instead. That's not an acceptable regression even if the app is technically broken. This has been reported with XFCE and FVWM, and Motif's cut-and-paste code has the same bug by inspection, so this does need to be addressed.
This change nerfs LockDisplay/UnlockDisplay while inside the critical bit of an IfEvent function. This is still safe in the sense that the display remains locked and no other thread should be able to change it from under us, but the loop that scans the event queue might not be robust against it being modified as a side effect of protocol emitted by the predicate callback. But that's not new, non-XInitThreads'd xlib would have the same caveat.
Closes: #157 (closed)
I have merely typed this up, not tested it, but I wanted to float the idea for discussion. This seems like it might be a minimal fix to allow the
XIfEvent predicate function to reenter xlib at least as safely as it did in the before times, without going all in on recursive mutexes or anything more extreme.