meta: update to std::future and release an alpha.

[carllerche]

This issue tracks the progress of updating Tokio to use std::future.

Crates to update

• tokio-codec (codec: update to std::future #1189).
• tokio-fs (fs: update to std::future #1192).
• tokio-signal (signal: update to std::future #1193).
• tokio-threadpool (threadpool: update to std::future #1200).
• tokio-tls (tls: update to std::future #1194).
• tokio-udp (udp: update to std::future #1195).
• tokio-uds (uds: update to std::future #1196).

Examples

The examples should be updated to idiomatic async / await syntax.

• blocking
• chat-combinator-current-thread
• chat-combinator
• chat
• connect
• echo-udp
• echo
• hello_world
• manual-runtime
• print_each_packet
• proxy
• tinydb
• tinyhttp
• udp-client
• udp-codec

Additional functionality

Besides requiring crates to have transitioned to std::future, some examples are blocked on additional functionality being added.

• I/O helpers (tokio: introduce I/O utility helpers #1203).

Alpha release

The first alpha release will happen once the examples have been updated.

[rubdos]

The first alpha release will happen once the examples have been updated.

I'll take some (if not all) examples on me. Feel free to ping me on Gitter, merge request incoming.

[archseer]

Note: while the tokio-threadpool crate was updated, the tokio crate itself is currently hardcoded to current_thread runtime. We should probably open an issue for that.

I tried porting the required modules but couldn't quite figure out what the updated code should look like.

[carllerche]

@archseer good call.

[CryZe]

Is there a reason AsyncRead and AsyncWrite are not just reexported from futures? These are causing incompatibility problems for me. If it's not intentional, I'll send a PR.

[seanmonstar]

@CryZe so far, that's been intentional. There's been desire to explore alternate method signatures.

What compatibility issues are there? With other libraries?

[carllerche]

@archseer bringing back the multi-threaded runtime: #1280

[archseer]

Thanks! With this I can now almost get things running (still tackling compat stuff). What I did notice though is that tokio-uds pulls in the tokio v0.1 crates because the dependency on it in tokio doesn't specify path ="../tokio-uds" I think:

https://github.com/tokio-rs/tokio/blob/master/tokio/Cargo.toml#L87

[rubdos]

FYI, proxy example at 914038e (rubdos/tokio/proxy-example) works now (with async fn accept()), but needs futures-preview. Feel free to pick that from my fork.

EDIT: accidentally pasted wrong commit. EDIT EDIT: accidentally thought to have pasted the wrong commit.

[rubdos]

Seems like all other examples depend on some decision like #1225, since some kind of Stream trait is basically required for nice async examples.

[alex]

Should tokio-tls be checked off? The issue it points at was resolved.

[carllerche]

@alex thanks 👍

[MOZGIII]

I've implemented a crate using futures-preview and now I'm trying to use it in my project with a master branch of tokio.

I'm getting this error:

error[E0277]: the trait bound `tokio_tcp::stream::TcpStream: futures_io::if_std::AsyncRead` is not satisfied

At this point, I know what's causing it, and that there is a workaround available to make tokio and futures-preview play nicely together (thanks to good people at rust's discord). I just wanted to share my current experience here, as well as the found workaround.

[osa1]

I think "chat", "udp-codec" and "tinydb" examples can be checked off as well.

[LucioFranco]

@osa1 thanks, its done!

An update, I think we want to get all the examples updated and do a final pass of the crates then we can start publishing alphas!

[Proximyst]

You forgot the TCP echo on the examples list :)

[rrichardson]

@seanmonstar wrote:

so far, that's been intentional. There's been desire to explore alternate method signatures.
What compatibility issues are there? With other libraries?

I might be missing something obvious, but it is awkward to use tokio::TcpStream and friends which implements tokio::AsyncRead/Write and reconcile that with much of the Futures API which expects its own AsyncRead/Write.

Is there an alternative to TcpStream that implements futures::Async* ?

[agausmann]

I'm working on reimplementing blocking example, and I discovered that tokio_threadpool::blocking returns a Poll. This is not very ergonomic in the current state of futures; I would likely have to use something like futures::poll_fn if one exists, or write my own future wrapping it. Is that something that we would want to turn into an async fn?

[LucioFranco]

@rrichardson you can use this compat layer for now https://github.com/nemo157/futures-tokio-compat/ we are still exploring the API a bit and the one in the futures crate isn't stable either.

@agausmann I believe we've been using https://github.com/tokio-rs/async/blob/master/async-util/src/future/poll_fn.rs#L34 but there is also https://docs.rs/futures-preview/0.3.0-alpha.17/futures/future/fn.poll_fn.html

[carllerche]

This was done! 🎉