Unfortunately in multi-threaded environment there's no way to handle errors safely other than setting error handling routine and store the error information in some thread safe structure like we do in winit with mutex.

However the problem with xlib here is that error handling callback is global for the entire process, so if glutin wants to make use of GLX, but doesn't want to depend on winit, it must get the error information out of winit somehow(glutin can call X related functions to perform all it wants, it just has no way to safely obtain errors from X11.

For more one could read https://www.remlab.net/op/xlib.shtml it has a pretty good explanation on that matter.

The thing with winit is that it already exposes the error via XConnection, however it's hidden from the end users and is being used internally by some crates that know about it.

So, I'd suggest to document that and expose last error from X11 in some more defined way. Either via proving it in some sort of Arc<Mutex<>> or via pointer to some function to call in hope to obtain the error information in a thread safe way.

Note, that XCB doesn't have mentioned issues in general, however GLX and some other APIs do require the use of Xlib unfortunately.

cc @maroider