-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smooth transition from 0.1 to 0.2 #1549
Comments
I'll file issues and attach them here for what I saw as the problems - the big issue is the bridge runtime, as you describe, then with some less significant issues around |
Issue #1551 for the async traits being out of sync between |
Issue #1552 for the runtime bridge, fleshing out what I want from it. |
And rust-lang/futures-rs#1865 for the compat I/O issues I found, assuming that #1551 is fixed. |
@carllerche Thanks for looking into the |
## Motivation The `futures` crate's [`compat` module][futures-compat] provides interoperability between `futures` 0.1 and `std::future` _future types_ (e.g. implementing `std::future::Future` for a type that implements the `futures` 0.1 `Future` trait). However, this on its own is insufficient to run code written against `tokio` 0.1 on a `tokio` 0.2 runtime, if that code also relies on `tokio`'s runtime services. If legacy tasks are executed that rely on `tokio::timer`, perform IO using `tokio`'s reactor, or call `tokio::spawn`, those API calls will fail unless there is also a runtime compatibility layer. ## Solution As proposed in #1549, this branch introduces a new `tokio-compat` crate, with implementations of the thread pool and current-thread runtimes that are capable of running both tokio 0.1 and tokio 0.2 tasks. The compat runtime creates a background thread that runs a `tokio` 0.1 timer and reactor, and sets itself as the `tokio` 0.1 executor as well as the default 0.2 executor. This allows 0.1 futures that use 0.1 timer, reactor, and executor APIs may run alongside `std::future` tasks on the 0.2 runtime. ### Examples Spawning both `tokio` 0.1 and `tokio` 0.2 futures: ```rust use futures_01::future::lazy; tokio_compat::run(lazy(|| { // spawn a `futures` 0.1 future using the `spawn` function from the // `tokio` 0.1 crate: tokio_01::spawn(lazy(|| { println!("hello from tokio 0.1!"); Ok(()) })); // spawn an `async` block future on the same runtime using `tokio` // 0.2's `spawn`: tokio_02::spawn(async { println!("hello from tokio 0.2!"); }); Ok(()) })) ``` Futures on the compat runtime can use `timer` APIs from both 0.1 and 0.2 versions of `tokio`: ```rust use std::time::{Duration, Instant}; use futures_01::future::lazy; use tokio_compat::prelude::*; tokio_compat::run_03(async { // Wait for a `tokio` 0.1 `Delay`... let when = Instant::now() + Duration::from_millis(10); tokio_01::timer::Delay::new(when) // convert the delay future into a `std::future` that we can `await`. .compat() .await .expect("tokio 0.1 timer should work!"); println!("10 ms have elapsed"); // Wait for a `tokio` 0.2 `Delay`... let when = Instant::now() + Duration::from_millis(20); tokio_02::timer::delay(when).await; println!("20 ms have elapsed"); }); ``` ## Future Work This is just an initial implementation of a `tokio-compat` crate; there are more compatibility layers we'll want to provide before that crate is complete. For example, we should also provide compatibility between `tokio` 0.2's `AsyncRead` and `AsyncWrite` traits and the `futures` 0.1 and `futures` 0.3 versions of those traits. In #1549, @carllerche also suggests that the `compat` crate provide reimplementations of APIs that were removed from `tokio` 0.2 proper, such as the `tcp::Incoming` future. Additionally, there is likely extra work required to get the `tokio-threadpool` 0.1 `blocking` APIs to work on the compat runtime. This will be addressed in a follow-up PR. Fixes: #1605 Fixes: #1552 Refs: #1549 [futures-compat]: https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-alpha.19/futures/compat/index.html
tokio-compat works like a charm! Looking forward to the regular release. |
Now that |
Original report: https://users.rust-lang.org/t/failed-to-port-mononoke-to-tokio-0-2-experience-report/32478
My read of this is that the primary issue is a lack of compat layers between 0.1 and 0.2.
tokio-compat
The solution would be to provide a crate that implements a bridge runtime, setting up the required bits to run both 0.1 and 0.2 on the same runtime. Additionally, a compat layer between 0.1 and 0.2 traits (primarily read and write).
Runtime
The
tokio-compat
crate would provide runtime types that mirror the API in Tokio 0.2. This runtime type would create both an 0.2 and 0.1 runtime simultaneously. It would not need to run two threadpool side by side, but it could bridge the two using a future compat layer. The compat runtime would need to spawn a single extra thread to run an 0.1 reactor & timer.APIs removed
Tokio 0.2 has hidden a number of APIs. For example, most of the I/O helper futures are now private. Same with
tcp::Incoming
.tokio-compat
should provide versions of these futures. The specific strategy by which this could be done is TBD.The text was updated successfully, but these errors were encountered: