Call to method on 'window' blocks when event loop in other thread is not awake

[sagacity]

I'm trying to construct my application in such a way that the winit (or really Glutin) event loop is on another thread, e,g.:

let events_loop = ...
let window = glutin::GlWindow::new(...pass in events_loop and windowbuilder, etc...)

thread::spawn(move || {
    events_loop.run_forever(|event| {
        ....convert events to other format and dispatch...
        ControlFlow::Continue
    });
);

This way my application is not "driven" by the winit event loop, it has just become a source of events for other parts of my code.

Anyway, the window I have is not moved to that thread, it's just the event loop that's running there. This works fine on Windows. Except on Wayland (Ubuntu) every method I invoke on window is blocked unless the event loop becomes momentarily awakened, like when I move my mouse:

// blocks!
let _ = window.get_inner_size_pixels().unwrap();

The same thing happens when calling swap_buffers on glutin's GlWindow. This will block unless the event loop is somehow awakened. Everything is fine, then.

Is this by design? Is it not supported to run the event loop on a separate thread?

[elinorbgr]

Indeed, the way the wayland backend is implemented, while the event loop is running it locks some resources exclusively, causing some methods of window to be blocking. This should obviously be improved, especially as these methods would deadlock if run from within the callback of run_forerever() ...

Now, on point that puzzles me is, looking back at the implementation, get_inner_size_pixels() is not one of the methods I would expect to see blocking, and the momentarily awakening would not have any impact on this blocking, as run_forever takes the lock until it returns.

So, this looks like your issue is something else. I'll try to reproduce your issue when I get some time in order to understand what's going on exactly. If you have a small runnable example reproducing the issue, this would be very helpful.

[sagacity]

I've done some more digging, it appears that the problem shows up when trying to make the GL window current in another thread. This was not completely what I described, so apologies there! I'm not 100% sure this is allowed but I believe it should be?

The repro case is here: https://github.com/RoyJacobs/winit-repro
On my machine it blocks here: https://github.com/RoyJacobs/winit-repro/blob/master/src/main.rs#L26

If I wiggle the mouse the application continues and also calls swap_buffers without issue.

I do get this warning at startup, but it seems unrelated:

[wayland-client] Found library libwayland-client.so cannot be used: symbol wl_proxy_marshal_array_constructor_versioned

[elinorbgr]

Oh, this warning is actually quite related. It means you have an old version of libwayland-client.so that winit cannot use, and as such it should have gone to fallback to using the X11 backend, via Xwayland.

To confirm this, can you run your example with the env variable WAYLAND_DEBUG=1 ? If you get nothing, then winit is using x11.

[sagacity]

Ahh, I feel stupid for missing that! Running with that environment variable gives me identical behavior, though. It appears I'm just running x11 (sigh, I'm definitely not a Linux expert).

The questions I have then:

• Is what I'm trying to do supported by x11 at all?
• If I'm just running x11, why is winit trying to load a wayland client?

Thanks for your patience with this, by the way 👍

[elinorbgr]

I'm no expert of X11, so I'll have to leave this to someone more knowledgeable... @Ralith maybe?

Regarding your second question: the linux ecosystem is more or less in a transition state from x11 to wayland, and during that, most wayland compositors will expose a compatibility layer named Xwayland so that X11 apps can still work with the new protocol.

To ensure max compatibility, when staed on linux, winit first tries to connect to a wayland server (as this is the most up-to-date approach), and in case of failure, fall-back to trying to connect to X11.

In your case, it looks like you have a wayland environment, but the version of the wayland libs you have is too old and missing some symbols winit needs, to use wayland, so the fallback to X11 triggers.

[sagacity]

In general I'm not 100% convinced what I'm doing is legal. The reproduction scenario fails to compile on OSX since objc::runtime::Object is not Send.

I'll probably just move everything into a separate thread instead of only the event loop.

[Ralith]

Where exactly does the call block? I didn't write the X11 Window code but I don't see any explicit locking in it, and afaik Xlib doesn't contain any that would lead to sustained blocking either.

[sagacity]

It's blocking in the call to make_current. If there are no locks it could potentially be an NVidia driver issue or just some undefined behavior?

As for me, I've refactored my code to avoid threading related to the window and event loop and am now using polling in my Tokio reactor code. This works on OSX and I'll check later today if it's also solving the issue on X11.

Edit: Can confirm everything works fine on X11 when I create everything on the main thread and just poll the event loop in a separate thread.

[sagacity]

I'll close this issue for now since it seems it was caused by using the library in a way that's not intended.