Integration with GUI event loop

[crlf0710]

GUI applications need to run its own GUI event loop. It would be nice to find a way to allow running the network IO event loop and GUI event loop together. Maybe someway to integrate with winit or a similar library.

And @yoshuawuyts mentioned that this should also be figured out for the browsers use case.

[yoshuawuyts]

@crlf0710 #22 adds browser support for runtime-native. Perhaps a similar approach could work for winit too? Though that would likely need to have its own runtime, rather than be part of runtime-native.

[crlf0710]

Thanks, i'm still playing with winit. winit used to have a "reactor" thread / "executor" thread separation but it's currently moving away from it (into a callback style API). And romio is another "reactor". I'm seeking for something that makes these two reactors work smoothly together. or maybe there's a better way of thinking. Will comment more when i have figured more details out.

[sdroege]

In this context it might also make sense to look at the glib crate, which provides bindings for the C GLib library. It has an GUI/IO event loop that is used e.g. by the GTK UI toolkit and asynchronous IO operations provided by libraries in the same ecosystem. And most interestingly, the glib crate implements a futures (0.3 / std) executor around that event loop and exposes async IO operations as futures.

One thing to keep in mind here is that integration might become a bit tricky. Similar to e.g. tokio futures having to run on a tokio runtime and not any other futures executor, the same thing is true for glib futures (e.g. they can't run on a tokio runtime).

I expect the same to be true for e.g. some winit based reactor/executor (especially as Windows APIs are very picky about which thread things run on).

[sdroege]

Related, https://github.com/rustasync/runtime/issues/42