Unfortunately I was not able to attend the Rust+GNOME hackfest in Madrid last week, but I could at least spend some of my work time at Centricular on implementing one of the things I wanted to work on during the hackfest. The other one, more closely related to the gnome-class work, will be the topic of a future blog post once I actually have something to show.
So back to the topic. With the latest GIT version of the Rust bindings for GLib, GTK, etc it is now possible to make use of the Rust futures infrastructure for GIO async operations and various other functions. This should make writing of GNOME, and in general GLib-using, applications in Rust quite a bit more convenient.
For the impatient, the summary is that you can use Rust futures with GLib and GIO now, that it works both on the stable and nightly version of the compiler, and with the nightly version of the compiler it is also possible to use async/await. An example with the latter can be found here, and an example just using futures without async/await here.
Table of Contents
Futures
First of all, what are futures and how do they work in Rust. In a few words, a future (also called promise elsewhere) is a value that represents the result of an asynchronous operation, e.g. establishing a TCP connection. The operation itself (usually) runs in the background, and only once the operation is finished (or fails), the future resolves to the result of that operation. There are all kinds of ways to combine futures, e.g. to execute some other (potentially async) code with the result once the first operation has finished.
It’s a concept that is also widely used in various other programming languages (e.g. C#, JavaScript, Python, …) for asynchronous programming and can probably be considered a proven concept at this point.
Futures in Rust
In Rust, a future is basically an implementation of relatively simple trait called Future. The following is the definition as of now, but there are discussions to change/simplify/generalize it currently and to also move it to the Rust standard library:
pub trait Future {
type Item;
type Error;
fn poll(&mut self, cx: &mut task::Context) -> Poll<Self::Item, Self::Error>;
}
Anything that implements this trait can be considered an asynchronous operation that resolves to either an Item or an Error. Consumers of the future would call the poll method to check if the future has resolved already (to a result or error), or if the future is not ready yet. In case of the latter, the future itself would at a later point, once it is ready to proceed, notify the consumer about that. It would get a way for notifications from the Context that is passed, and proceeding does not necessarily mean that the future will resolve after this but it could just advance its internal state closer to the final resolution.
Calling poll manually is kind of inconvenient, so generally this is handled by an Executor on which the futures are scheduled and which is running them until their resolution. Equally, it’s inconvenient to have to implement that trait directly so for most common operations there are combinators that can be used on futures to build new futures, usually via closures in one way or another. For example the following would run the passed closure with the successful result of the future, and then have it return another future (Ok(()) is converted via IntoFuture to the future that always resolves successfully with ()), and also maps any errors to ()
fn our_future() -> impl Future<Item = (), Err = ()> {
some_future
.and_then(|res| {
do_something(res);
Ok(())
})
.map_err(|_| ())
}
A future represents only a single value, but there is also a trait for something producing multiple values: a Stream. For more details, best to check the documentation.
Async/Await
The above way of combining futures via combinators and closures is still not too great, and is still close to callback hell. In other languages (e.g. C#, JavaScript, Python, …) this was solved by introducing new features to the language: async for declaring futures with normal code flow, and await for suspending execution transparently and resuming at that point in the code with the result of a future.
Of course this was also implemented in Rust. Currently based on procedural macros, but there are discussions to actually move this also directly into the language and standard library.
The above example would look something like the following with the current version of the macros
#[async]
fn our_future() -> Result<(), ()> {
let res = await!(some_future)
.map_err(|_| ())?;
do_something(res);
Ok(())
}
This looks almost like normal, synchronous code but is internally converted into a future and completely asynchronous.
Unfortunately this is currently only available on the nightly version of Rust until various bits and pieces get stabilized.
Tokio
Most of the time when people talk about futures in Rust, they implicitly also mean Tokio. Tokio is a pure Rust, cross-platform asynchronous IO library and based on the futures abstraction above. It provides a futures executor and various types for asynchronous IO, e.g. sockets and socket streams.
But while Tokio is a great library, we’re not going to use it here and instead implement a futures executor around GLib. And on top of that implement various futures, also around GLib’s sister library GIO, which is providing lots of API for synchronous and asynchronous IO.
Just like all IO operations in Tokio, all GLib/GIO asynchronous operations are dependent on running with their respective event loop (i.e. the futures executor) and while it’s possible to use both in the same process, each operation has to be scheduled on the correct one.
Futures & GLib/GIO
Asynchronous operations and generally everything event related (timeouts, …) are based on callbacks that you have to register, and are running via a GMainLoop that is executing events from a GMainContext. The latter is just something that stores everything that is scheduled and provides API for polling if something is ready to be executed now, while the former does exactly that: executing.
Callbacks
The callback based API is also available via the Rust bindings, and would for example look as follows
glib::timeout_add(20, || {
do_something_after_20ms();
glib::Continue(false) // don't call again
});
glib::idle_add(|| {
do_something_from_the_main_loop();
glib::Continue(false) // don't call again
});
some_async_operation(|res| {
match res {
Err(err) => report_error_somehow(),
Ok(res) => {
do_something_with_result(res);
some_other_async_operation(|res| {
do_something_with_other_result(res);
});
}
}
});
As can be seen here already, the callback-based approach leads to quite non-linear code and deep indentation due to all the closures. Also error handling becomes quite tricky due to somehow having handle them from a completely different call stack.
Compared to C this is still far more convenient due to actually having closures that can capture their environment, but we can definitely do better in Rust.
The above code also assumes that somewhere a main loop is running on the default main context, which could be achieved with the following e.g. inside main()
let ctx = glib::MainContext::default(); let l = glib::MainLoop::new(Some(&ctx), false); ctx.push_thread_default(); // All operations here would be scheduled on this main context do_things(&l); // Run everything until someone calls l.quit() l.run(); ctx.pop_thread_default();
It is also possible to explicitly select for various operations on which main context they should run, but that’s just a minor detail.
GLib Futures
To make this situation a bit nicer, I’ve implemented support for futures in the Rust bindings. This means, that the GLib MainContext is now a futures executor (and arbitrary futures can be scheduled on it), all the GSource related operations in GLib (timeouts, UNIX signals, …) have futures- or stream-based variants and all the GIO asynchronous operations also come with futures variants now. The latter are autogenerated with the gir bindings code generator.
For enabling usage of this, the futures feature of the glib and gio crates have to be enabled, but that’s about it. It is currently still hidden behind a feature gate because the futures infrastructure is still going to go through some API incompatible changes in the near future.
So let’s take a look at how to use it. First of all, setting up the main context and executing a trivial future on it
let c = glib::MainContext::default();
let l = glib::MainLoop::new(Some(&c), false);
c.push_thread_default();
// Spawn a future that is called from the main context
// and after printing something just quits the main loop
let l_clone = l.clone();
c.spawn(futures::lazy(move |_| {
println!("we're called from the main context");
l_clone.quit();
Ok(())
});
l.run();
c.pop_thread_default();
Apart from spawn(), there is also a spawn_local(). The former can be called from any thread but requires the future to implement the Send trait (that is, it must be safe to send it to other threads) while the latter can only be called from the thread that owns the main context but it allows any kind of future to be spawned. In addition there is also a block_on() function on the main context, which allows to run non-static futures up to their completion and returns their result. The spawn functions only work with static futures (i.e. they have no references to any stack frame) and requires the futures to be infallible and resolve to ().
The above code already showed one of the advantages of using futures: it is possible to use all generic futures (that don’t require a specific executor), like futures::lazy or the mpsc/oneshot channels with GLib now. And any of the combinators that are available on futures
let c = MainContext::new();
let res = c.block_on(timeout_future(20)
.and_then(move |_| {
// Called after 20ms
Ok(1)
})
);
assert_eq!(res, Ok(1));
This example also shows the block_on functionality to return an actual value from the future (1 in this case).
GIO Asynchronous Operations
Similarly, all asynchronous GIO operations are now available as futures. For example to open a file asynchronously and getting a gio::InputStream to read from, the following could be done
let file = gio::File::new_for_path("Cargo.toml");
let l_clone = l.clone();
c.spawn_local(
// Try to open the file
file.read_async_future(glib::PRIORITY_DEFAULT)
.map_err(|(_file, err)| {
format!("Failed to open file: {}", err)
})
.and_then(move |(_file, strm)| {
// Here we could now read from the stream, but
// instead we just quit the main loop
l_clone.quit();
Ok(())
})
);
A bigger example can be found in the gtk-rs examples repository here. This example is basically reading a file asynchronously in 64 byte chunks and printing it to stdout, then closing the file.
In the same way, network operations or any other asynchronous operation can be handled via futures now.
Async/Await
Compared to a callback-based approach, that bigger example is already a lot nicer but still quite heavy to read. With the async/await extension that I mentioned above already, the code looks much nicer in comparison and really almost like synchronous code. Except that it is not synchronous.
#[async]
fn read_file(file: gio::File) -> Result<(), String> {
// Try to open the file
let (_file, strm) = await!(file.read_async_future(glib::PRIORITY_DEFAULT))
.map_err(|(_file, err)| format!("Failed to open file: {}", err))?;
Ok(())
}
fn main() {
[...]
let future = async_block! {
match await!(read_file(file)) {
Ok(()) => (),
Err(err) => eprintln!("Got error: {}", err),
}
l_clone.quit();
Ok(())
};
c.spawn_local(future);
[...]
}
For compiling this code, the futures-nightly feature has to be enabled for the glib crate, and a nightly compiler must be used.
The bigger example from before with async/await can be found here.
With this we’re already very close in Rust to having the same convenience as in other languages with asynchronous programming. And also it is very similar to what is possible in Vala with GIO asynchronous operations.
The Future
For now this is all finished and available from GIT of the glib and gio crates. This will have to be updated in the future whenever the futures API is changing, but it is planned to stabilize all this in Rust until the end of this year.
In the future it might also make sense to add futures variants for all the GObject signal handlers, so that e.g. handling a click on a GTK+ button could be done similarly from a future (or rather from a Stream as a signal can be emitted multiple times). If this is in the end more convenient than the callback-based approach that is currently used, is to be seen. Some experimentation would be necessary here. Also how to handle return values of signal handlers would have to be figured out.