Winit: Event loop proxy's `wakeup` not waking event loop up

[chrisduerr]

This has been reported to Alacritty in https://github.com/jwilm/alacritty/issues/2217, more information can be found there.

It looks like an attempt to wake up the event loop through the event loop proxy's wakeup can fail until other winit events are received.

This is problematic because Alacritty relies on blocking for the event loop and calling wakeup when an update to the terminal has been made. As a result of this bug it's possible that the terminal updates (imagine running yes), but the event loop doesn't wake up for drawing, making it look like the application has frozen (because it has).

[pappasam]

@chrisduerr I've experimented with the various commits since Version 0.18.1 and have narrowed it down one change in the following commit: 9ea2810b4615f21563b001949fe7f97bb91d3bea

Note: at this time, I do not understand exactly why the code in question is causing display problems in Alacritty. I've only determined that it does; could be a problem with Glutin, Alacritty, or Winit. Either way, the problem's solution will involve understanding differences between XCheckIfEvent and XNextEvent.

• XCheckIfEvent man page
• XNextEvent man page

Purpose of Commit (from CHANGELOG)

"On X11, make event loop thread safe by replacing XNextEvent with select(2) and XCheckIfEvent"

Part of commit directly causing problems for Alacritty

Replacing XNextEvent with XCheckIfEvent

Problematic code

The relevant updates live in src/platform/linux/x11/mod.rs, in the EventsLoop implementation function "unsafe fn poll_one_event". The event loop's inability to wake up is fixed in Alacritty by reverting the following element of the commit to its old code:

The new, problematic code uses this new, likely-problemmatic function. I believe this function is directly causing Alacritty's display problems in X11:

How I narrowed it down

I was able to narrow it down to just this code because Alacritty relies on glutin to interact with winit. Glutin makes no reference to the "run_forever" function and only relies on "poll_events". Because of this, I haven't investigated the impact of the function "wait_for_input"; it may be problemmatic too, but its lack of relevance of Alacritty hasn't incentivized me to investigate.

[Osspial]

Does this get fixed by #842? cc @vberger

[pappasam]

@Osspial unfortunately, it does not solve this issue, at least for me. I've tested Alacritty using winit from vberger:evl2 and experienced the same window freezing effects. The problem does not appear worse, so your PR probably hasn't done any harm regarding this issue!

[vberger]

Alacritty is already ported to the new evl2 API? Is this code available somewhere? It'd greatly facilitate testing.

[chrisduerr]

@vberger If it is, I'm not aware of it. So I'd assume @pappasam might have run the wrong branch?

Unless he's ported it himself, in which case I'd also like to see the source changes necessary.

[pappasam]

@vberger @chrisduerr Apologies, was unaware this introduced api changes. I simply cloned your forked winit locally, checked out the evl2 branch, added winit as an explicit local path dependency in alacritty, and rebuilt alacritty. If using this new event loop requires api changes within either Glutin or Alacritty, then ignore my comment above.

[pappasam]

The Cargo.toml changes I made (after cloning this branch locally):

winit = { path = "./winit" }

[chrisduerr]

Alacritty doesn't have any direct dependency on winit. You'd have to either add it to the patch section or clone glutin, and winit, set the winit as relative path in glutin and then setup glutin as relative path in Alacritty.

So adding a winit dependency to Alacritty directly will just get it ignored.

[vberger]

In anyway, to answer your original question @Osspial : I'd expect the evl2 port to fix this, given winit using calloop will wait on both x11 events and user events conccurently. But I'd not be 100% sure until it can be properly tested.

Can this issue be reproduced with a simple pre-evl2 winit program?

[Osspial]

@chrisduerr Is this an issue on Alcritty using EL2?

[chrisduerr]

It is not, the Event Loop 2 fixes this issue, simply because the method doesn't exist anymore. I was not able to reproduce similar issues with the send_event method either.