Skip to content
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

Closed
carllerche opened this issue Sep 12, 2019 · 7 comments
Closed

Smooth transition from 0.1 to 0.2 #1549

carllerche opened this issue Sep 12, 2019 · 7 comments
Assignees

Comments

@carllerche
Copy link
Member

carllerche commented Sep 12, 2019

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.

@carllerche carllerche added this to the v0.2 milestone Sep 12, 2019
@farnz
Copy link
Contributor

farnz commented Sep 13, 2019

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 AsyncRead/AsyncWrite, one of which I think belongs to futures not tokio.

@farnz
Copy link
Contributor

farnz commented Sep 13, 2019

Issue #1551 for the async traits being out of sync between tokio and futures.

@farnz
Copy link
Contributor

farnz commented Sep 13, 2019

Issue #1552 for the runtime bridge, fleshing out what I want from it.

@farnz
Copy link
Contributor

farnz commented Sep 13, 2019

And rust-lang/futures-rs#1865 for the compat I/O issues I found, assuming that #1551 is fixed.

@vojtechkral
Copy link
Contributor

@carllerche Thanks for looking into the Incoming problem. I think I thought it was a mistake rather than intent because uds::Incoming was/is public. What is the future intent for incoming() - will it return an existential type?

hawkw added a commit that referenced this issue Nov 1, 2019
## 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
@carllerche carllerche removed this from the v0.2 milestone Nov 22, 2019
@h4x3rotab
Copy link

h4x3rotab commented Dec 12, 2019

tokio-compat works like a charm! Looking forward to the regular release.

@hawkw
Copy link
Member

hawkw commented Mar 30, 2020

Now that tokio-compat has been published for a while, I think we can close this.

@hawkw hawkw closed this as completed Mar 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants