|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "Futures 0.3.0-alpha.2" |
| 4 | +author: "Josef Brandl" |
| 5 | +author_github: "MajorBreakfast" |
| 6 | +date: 2018-01-01 |
| 7 | +categories: blog |
| 8 | +--- |
| 9 | + |
| 10 | +`alpha.2` requires a recent nightly (2018-xx-xx or newer): |
| 11 | +```sh |
| 12 | +$ rustup update |
| 13 | +``` |
| 14 | + |
| 15 | +## What's new? |
| 16 | + |
| 17 | +### Refined definition for "task" |
| 18 | + |
| 19 | +The documentation for the `Executor` trait was updated. It now defines a "task executor" like this: |
| 20 | + |
| 21 | +> Futures are polled until completion by tasks, a kind of lightweight "thread". A *task executor* is responsible for the creation of these tasks and the coordination of their execution on real operating system threads. In particular, whenever a task signals that it can make further progress via a wake-up notification, it is the responsibility of the task executor to put the task into a queue to continue executing it, i.e. polling the future in it, later. |
| 22 | +
|
| 23 | +The notable difference to before is that the term "task" no longer refers to the future that the task runs. Instead, from now on, the term "task" only refers to the concept of a "lightweight" thread, a kind of thread that doesn't directly correspond to a thread provided by the operating system. This concept is sometimes also referred to as "green thread" - We, however, do not use either these terms because they tend to cause confusion with real operating system threads. Instead, we call this concept a "task" and the thing that runs them "task executor" or often just "executor". |
| 24 | + |
| 25 | +### `Try` impl for `Poll` |
| 26 | + |
| 27 | +The [`Poll`](https://doc.rust-lang.org/nightly/core/task/enum.Poll.html) enum now implements the [`Try`](https://doc.rust-lang.org/std/ops/trait.Try.html) trait. This means you can now do this: |
| 28 | + |
| 29 | +```rust |
| 30 | +fn poll(mut self: PinMut<Self>, cx: &mut task::Context, ) -> Poll<Result<T, E>> { |
| 31 | + let poll: Poll<Result<T, E>> = self.future().poll(); |
| 32 | + let poll: Poll<T> = poll?; // Returns from function if its an error |
| 33 | + let ok_value: T = ready!(poll); // Returns from function if not ready |
| 34 | + |
| 35 | + // Or short: |
| 36 | + let ok_value = ready!(self.future().poll()?); |
| 37 | +} |
| 38 | +``` |
| 39 | + |
| 40 | +- The `?`-operator used on a `Poll<Result<T, E>>` value: |
| 41 | + - yields `Poll::Pending` from the expression if the value is not ready. |
| 42 | + - yields `Poll::Ready(ok_value)` from the expression if the value is ready and successful. |
| 43 | + - returns `Poll::Ready(Err(err_value))` from the function if the value is ready and an error. |
| 44 | +- The `ready!` macro used on a `Poll<T>` value: |
| 45 | + - yields the value of type `T` from the expression if the value is ready. |
| 46 | + - returns `Poll::pending` from the function if the value is not ready. |
| 47 | + |
| 48 | +Additionally `Try` was also implemented for `Poll<Option<Result<T, E>>>`, more details on that in the [pull request](https://github.com/rust-lang/rust/pull/52721). |
| 49 | + |
| 50 | +### Changes to futures-rs |
| 51 | + |
| 52 | +We revived the [changelog](https://github.com/rust-lang-nursery/futures-rs/blob/master/CHANGELOG.md)! |
| 53 | + |
| 54 | +No major changes happened to the futures crate since the last release. There were, however, numerous little changes. Take a look at the [changelog](https://github.com/rust-lang-nursery/futures-rs/blob/master/CHANGELOG.md) to get an overview. |
| 55 | + |
| 56 | +## What are we currently working on? |
| 57 | + |
| 58 | +### Compatiblity layer for futures 0.1 |
| 59 | + |
| 60 | +We are currently working on an officially supported compatibility layer between `0.1` and `0.3`. This shim will make it possible to mix `0.1` futures with those from the 0.3 branch. The plan is to make it possible to use crates from the existing futures `0.1` ecosystem together with async functions and futures from the `0.3` crate. Additionally, this compatibility layer will also make it possible to gradually migrate exisiting applications and libraries to `0.3`. If you're curious, take a look the the [compatibility layer PR](https://github.com/rust-lang-nursery/futures-rs/pull/1119) and the [issue in the net-wg repository](https://github.com/rust-lang-nursery/net-wg/issues/26). |
0 commit comments