Ensure the event loop model is sound

[mzabaluev]

We have the GMainLoop event loop(s) which many GLib based libraries rely on for running. We also have Rust task event loops that are based on libuv. Interaction between the two is bound to be interesting. This is another part of the puzzle together with #2 and #3.

[mzabaluev]

Of interest: rust-lang/rust#4419

[mzabaluev]

Rust C runtime API is tracked in rust-lang/rust#1682.

[mzabaluev]

As part of the solution to #2, there is now a default GMainContext lazily created for every Rust thread. Now we can add an API for a task to create a GMainLoop using such a thread-local context and run it.

[mzabaluev]

Done as of 5d81d4e.
Rust tasks get to create and run their own thread-local GLib event loops. A task running an EventLoop is blocked for Rust event loop purposes.

[mzabaluev]

Reopening. 1cb7ca9 demonstrates a blocking problem: running a GMainLoop blocks the whole scheduler thread with all its tasks.

Fixing this will require deep modifications to GLib's event loop implementation. Fortunately, I have an ambition to do just that.

[mzabaluev]

So, I've got a GLib hack pending review, and a libuv integration for it.

While I was at it, Rust 0.9 has removed part of the problem by introducing a 1:1 runtime. If we restrict this GLib binding to be exclusively used with the 'native' runtime, it removes all issues with blocking in GMainContext polls, correct operation of async invoke, etc.

In contrast, making GLib work with the 'green' M:N runtime using the solution referenced above, apart from getting the GLib changes accepted, poses a number of remaining challenges, such as getting access to the libuv event loop of the task scheduler (besides the current API feasibility, this means not only explicit dependency on libgreen, but also on librustuv which is meant to be just one of future rtio backends), and resolving some corner cases not supported by the polling implementation of libuv (mzabaluev/glib-uv#1, mzabaluev/glib-uv#2).

Another approach worth looking into, as suggested by Colin Walters, is to supply a GLib-based implementation of std::rtio as an alternative to libuv event loops for the green runtime.

In all, it appears that it's not possible to make Grust agnostic to the newly found multitude of Rust runtimes. Aligning with the native runtime seems to be the most straightforward and useful way to proceed, as applications that I'd expect to use GLib-based components wouldn't likely benefit a lot from M:N task scheduling. But keeping all the other options in mind, it makes sense to provide a Rust-side abstraction for run/quit calls, with a view that the underlying GMainLoop might be running multiple Rust tasks in some future version of the library.

[mzabaluev]

The issue is going to be completely obsoleted by Rust RFC 0062.
The mapping between GMainLoop and its Rust representation should be almost direct, except that we want to disallow most operations besides quit() and get_context(), and provide a RAII wrapper around creating a GMainContext and pushing it as the thread default. This wrapper can run its internal GMainLoop object constructed around the context, and provide a refcounted reference to the loop object, which can be sent to callbacks and will provide quit().

[mzabaluev]

Fixed by the soon-to-be-only native runtime of current Rust, native::MainLoop, and native::LoopRunner.