Using `XNextEvent` in `EventsLoop` is not thread safe

[rikusalminen]

The EventsLoop on X11 backend uses XNextEvent to poll and wait for events which is not thread safe.

XNextEvent will hold the global Xlib mutex while blocked waiting for input, which causes a deadlock when other threads try to use X11, e.g. when calling make_current for a GL context.

The workaround is to use select or poll to wait for input on the X11 socket file descriptor and then use a non-blocking function like XCheckIfEvent to grab the events from the event queue. This is a rather ugly workaround to an ugly Xlib limitation.

Here is my work-in-progress fix to this problem: https://github.com/rikusalminen/winit/tree/waitevent

This patch is not quite complete and I'm seeing some strange issues with CloseRequested events which I can't quite explain. Some further debugging is required. Any help with testing and debugging is welcome. edit: fixed!

This bug also introduces an error handling conondrum. XNextEvent and other X11 functions do not return an error code, but poll will return error codes, some of which may be fatal errors. EventsLoop::runForever does not return a Result or other error code. I don't know what the right solution is (which would be compatible with other backend). Please advice how to proceed with this. edit: solved with assert! and panic! for fatal error conditions.

Additionally, a multi-threaded example/test case would be useful to verify that this problem is solved.

This issue is the root cause in several open issues for winit. At least the following bugs look like they are caused by this: #757, #420, #239 .

NOTE: I also fixed this same issue in GLFW back in 2012:
glfw/glfw@3d6221c#diff-0f3106b1408d89cbecbe2f57a783331b

[rikusalminen]

This patch should now work as expected.

Earlier versions had an issue where poll() was used after every event, blocking unnecessarily if more than one event arrived at the same time.

I changed from poll(2) to select(2).

I sorted the error handling issue by using assert! and panic! because all error conditions from select(2) are fatal conditions that should never occur.

This change does not check for exceptional conditions in the FD, such as the file descriptor being closed. This probably doesn't happen in normal conditions, but may occur if X11 server is killed. If these conditions should be checked, the exceptfds parameter to select(2) can be used, and I left a comment in the code where it should be.

Please excuse any white space issues, I just changed to a different text editor and I was having some issues with indentation. Feel free to use rustfmt to fix it.