04 Jan 2017

The concurrency story of capnp-rpc-rust gets a major update in today’s version 0.8 release. Previously, the remote procedure call system was built on top of GJ, an event loop framework designed specifically for Cap’n Proto, described in some of my previous posts. The new version drops GJ in favor of futures-rs, a library that is quickly becoming the standard foundation for asynchronous programming in Rust.

At the level of types, the update is fairly straightforward. The main asynchronous building block in GJ is the struct Promise<T, E> , representing a Result<T, E> that might not be ready yet. To migrate to futures-rs, each gj::Promise<T,E> can be translated into a Box<futures::Future<Item=T,Error=E>> , and the high-level structure of a program usually does not need to change.

Many nice properties derive from the fact that Future is a trait, not a struct, and does not need to be put in a Box . Concrete types implementing Future can be used in generics, making it possible for combinators like .then() and .join() to avoid heap allocations and to avoid losing type information. In particular, the typechecker can know at compile time whether it is safe to send a future between threads!

The Rust community has a growing ecosystem of libraries based on futures-rs, and today’s capnp-rpc-rust release should work well with all of them. For example, a Cap’n Proto method could invoke futures-cpupool to distribute computation-heavy work among a pool of worker threads, or it could use one of the emerging asynchronous database drivers to make queries on a remote database, or it could do, well, anything that can be expressed in terms of the Future trait. As a quick demonstration, I have implemented a simple example that uses tokio-curl to make asynchronous HTTP requests.

There are many exciting possibilities to explore. If any of this sounds interesting to you, I encourage you to get involved! Join me for discussion at #sandstorm on freenode IRC or at the tokio gitter.

-- posted by dwrensha