Integration with async ecosystem

[dylanede]

At the moment, I believe it is unclear how to best integrate futures and asynchronous execution in an application with a winit event loop. Ideally, I would imagine that futures/streams could be created for events (e.g. a stream for window resize events), and some special executor would run on the current thread that internally calls EventLoop::run. I am not sure however how to integrate this with, for example, tokio. Perhaps this is all something that could be built in a separate crate on top of winit, though I think this is the best place to discuss it.

The main immediate benefit I see of futur-ising the API is allowing state machines involving user input to be written much more naturally using async functions.

[goddessfreya]

I think @Osspial been working on something async related.

[Osspial]

I don't think Winit async/await support should live in the main repository, since it can be cleanly implemented on top of Winit's existing event loop API, it isn't necessary in all cases, and there's much more room for creating an opinionated API. However, I'd be alright with rust-windowing endorsing an official async wrapper for Winit.

Also, I have worked on an async wrapper, although it doesn't work on master quite yet. You can check it out here. https://github.com/osspial/winit-async

[elliegoldstein]

One fairly significant papercut I've run into when working on my own async event loop wrapper is that it's very difficult to manage the lifetimes required to create a window during the execution of the Future.

[alvinhochun]

This is only a rough idea as I am not too familiar with the async ecosystem: The web backend currently uses an exception as a hack to never return from EventLoop::run, but I've read that wasm-bindgen supports Future, which means it might be possible to make an EventLoop::async_run which doesn't use an exception, but instead returns a Future that completes when the loop has ended. It might also be possible to make an async-based polling API.

I'm not sure how this plays with the existing event loop model and on other platforms.

[FredrikNoren]

Here's a small example of how to get winit+wgpu+tokio working: https://gist.github.com/FredrikNoren/7c3535b11e99e8fcd8dd3d55f9a934a2

[exellian]

I noticed something which is impossible to do with the current design of the event loop:
Let's assume you would want an async runtime but single threaded that runs on the same thread as the event loop (low overhead).
Now you want to create a new window in this async context.
Because we as a developer don't have control over the loop which is behind event_loop we would have to
do something like this:

let runtime = tokio::runtime::Builder::new_current_thread()
        .enable_all()
        .build()
        .unwrap();
event_loop.run(move |event, target, cf| {

      runtime.block_on(async {
            let l = target; // Lifetime error can't borrow target
            //build window with target 
      });
});

The problem is that we cannot borrow the EventLoopTarget because it doesn't satisfy the 'static lifetime requirements of the tokio block_on method. So in a single threaded context this problem is not solvable because we can't communicate with the outer loop and get a response. If we use a multi threaded tokio runtime we could solve the problem by using channels (see: e.g: mpsc::channel) but this doesn't work on a single thread.
In addition this example doesn't execute the async blocks concurrently on a single thread but only in a sequential way, which is not ideal. Therefore it is necessary to be able to control the loop of the EventLoop. With the old approach by polling and waiting events manually (See design change #459) this problem would be solvable, but with the current design the best we can do to integrate async is to use at least two threads, which is limiting.
ps: I could also think of a EventLoop::async_run as proposed above, which itself is a async call and takes an async closure.

[maroider]

Your example is trivially fixed by adding a move, as is done in most of winit's examples.

- event_loop.run(|event, target, cf| {
+ event_loop.run(move |event, target, cf| {

I also can't see a 'static bound on Runtime::block_on's signature: pub fn block_on<F: Future>(&self, future: F) -> F::Output.

[exellian]

Your example is trivially fixed by adding a move, as is done in most of winit's examples.

- event_loop.run(|event, target, cf| {
+ event_loop.run(move |event, target, cf| {

I also can't see a 'static bound on Runtime::block_on's signature: pub fn block_on<F: Future>(&self, future: F) -> F::Output.

Ok thanks you are right Runtime::block_on actually doesn't require 'static lifetime so the borrowing problem is obsolete. But still the problem is that Runtime::block_on blocks the thread and therefore no events in the meantime will be registered. So i don't see that there is a truly async single threaded event_loop possible with the current design. Only if you would use more than one thread and use channels?

ps:
I could think of polling the futures manually in the event loop, but this leads again to the problem how a future would have a reference to the EventLoopTarget:

// No way that this future has a reference to the EventLoopTarget
let test = async {
    //create window here
};
event_loop.run(|event, target, cf| {
    // Own schedular that polls futures
    test.poll(...)
});

[Liamolucko]

I could think of polling the futures manually in the event loop, but this leads again to the problem how a future would have a reference to the EventLoopTarget:

// No way that this future has a reference to the EventLoopTarget
let test = async {
    //create window here
};
event_loop.run(|event, target, cf| {
    // Own schedular that polls futures
    test.poll(...)
});

This would ideally be possible by passing an async function, and then calling it with target on the first call of the event handler; however, that doesn't work, because target only lives for as long as that call of the event loop handler.

I thought I could solve it by changing EventLoop::run to look like this:

pub fn run<F>(self, event_handler: F) -> !
where
    F: 'static + FnMut(Event<'_, T>, &'static EventLoopWindowTarget<T>, &mut ControlFlow);

That's not valid, though, because of the possibility of the event handler panicking, and the panic being caught by catch_unwind; in that case, the program could continue after the EventLoop was dropped, invalidating the 'static lifetime.

Even if EventLoop::run were to catch panics and abort instead of unwinding, it still wouldn't work on the web; the event loop doesn't close the web page when it's destroyed, and user code can keep running through event listeners and callbacks and such. That could be changed, but feels quite hacky (albeit not much worse than throwing an exception from EventLoop::run).

[rib]

just thinking out loud...

I would imagine that it could help if winit event loop backends were based on the mio reactor, including exposing a standard API for registering event sources (e.g. based on file descriptors) that can trigger custom even loop wakeups.

I think mio is the API that tokio uses for blocking on IO (as a wrapper around epoll/kqueue) and I could imagine there'd be some way to join the dots by getting a tokio runtime to defer to the mio reactor of the winit event loop whenever the runtime is idle waiting for new input before polling.

This would act like a single threaded tokio runtime. (I think it'd make sense in this context to only support running tasks in the main loop thread, since practically speaking there are lots of platform-specific quirks that mean large swathes of the winit API are only usable from the UI thread). Apps could always spawn their own multi-threaded runtimes in a thread they create if they have other tasks that don't interact with the UI.

That's just based on my understanding of how a typical unix main loop works, e.g. things like libuv and glib's mainloop which tend to provide an extensible API for adding sources, which winit doesn't current seem to have an equivalent for, even though the event loops still boil down to the exact same kind of block on poll() design.

From quickly poking at tokio I don't see an obvious escape hatch for accessing the reactor state from the public API though so maybe it's not really possible. Maybe the opposite would be possible - to add all winit event sources to tokio's reactor. Certainly the X and Android backends are based on thin epoll wrappers and it'd perhaps be feasible to move all the file descriptors over to tokio. The Wayland backend is built on a slightly more elaborate polling abstraction but it should also be easy to pull the file descriptors out of that.

For iOS/mac it looks like they have a CFRunLoop abstraction over kqueue with apis for accessing the main/current thread loop where it might be possible to create a run loop source that's based on the file descriptors of an mio reactor (hard to imagine that be possible without a funky custom branch of mio).

Otherwise maybe there'd be some trick for getting a tokio runtime to poll in one thread but execute tasks in another so there would be a kind of side-car thread for blocking on tokio IO events and whenever it wakes up it would somehow wake up the event loop thread and then actually execute the tokio runtime tasks on that thread. I guess that kind of model would be required with Windows too.

Every mainloop library I've looked at has always had to do weird stuff for Windows, so I guess that would be a pita to handle too :)