Repository navigation
Updating to std::future::Future #1805
Description
Activity
I might be missing something, but is there a tracking issue on Tower to support 0.3 futures?
You say you are just considering it, but would TLS (Thread Local Storage, I presume) play well with Tokio's multi-threaded executor and, for example with conditional calls to
tokio_threadpool::blockingin (Body)Streams andSinks?That should be fine. When calling
pollmethods, we'd still need to materialize theContextbefore doing so, so there'd be no relying on other libraries keeping things on the same thread. It's more just wanting to reduce the noise of having to pass aContextto many methods ofproto::h1::Connthat don't always need it, but might poll the IO.Reacted by David KellumMost of the dependencies needed are updated in tokio's std-future branch. Disabling tokio-threadpool and h2 should hopefully be enough to start a branch here.
It's probably not worth figuring out some TLS Context thingy, and just passing the argument everywhere.
Reacted by memoryruins, Mathspy, quininer, Chadrick, Laurențiu Nicola, Kat Marchán, vultix and Jakub Beránek- Reacted by Grzegorz Szeliga, Sean McArthur, runiq, Jakub Beránek and Alexandro de Oliveira
#1836 is the PR for this, it's pretty close. Most things work (minus h2), and I have some local work to remove much of added unsafety, which I hope to have ready Monday. I'll likely merge that into master with docs and tests disabled, to allow those things to be worked on in parallel.
Reacted by memoryruins, Doug Tangren, Mathspy, Damir Vandic, Tux3 and Peter HueneReacted by Doug Tangren, Grzegorz Szeliga, Mathspy and Corbin UseltonMaster is now tracking 0.13, and #1836 was merged into it. It lacks HTTP2 support, an unsafe pin audit, and all the tests and examples were disabled, but hopefully those can be worked on in parallel.
Reacted by Peter Huene, Lucio Franco, Mathspy, Weihang Lo, Damir Vandic, Zimon Tai, runiq and Tux3Thanks everyone for working on this! I'm a bit confused about one thing though - is the move to
std::future::Futureintentionally also a move to async / await? I was assuming I could build a library with MSRV 1.36 that's going to be using hyper 0.13, but a bunch of code has already been committed that relies on#![feature(async_await)]instead of only theFuturetrait. Is it just too much hassle to convert to the newFuturefirst, and start using async / await later? (which should purely be an implementation detail)tokio 0.2usesawaitAFAIK.Thanks. I asked on the tokio Gitter channel; apparently they want to only release
0.2once async_await is stabilized.Reacted by Linus Färnstrand@seanmonstar are there plans to migrate
BodytoAsyncReadinstead of being aStream<Item = Chunk>? If it usesAsyncReadI can add async implementations tomultipartand abandonmultipart-async. I'm wondering if I should maintain two different crates anyway as the ecosystem seems to be migrating wholesale to async.@abonander Might be a tricky tricky to do so for a few reasons:
- Body isn't really a
Stream<Item = Chunk>, it's aPayload. - AsyncRead doesn't—to the best of my knowledge—have the equivalent of
Payload::poll_trailers, which is needed H/2 connections. The closest thing seems to be http-body, but that isn't AsyncRead.
Personally, I'd love to have a shared interface/trait at the moment for the reasons you outlined, but I'm not confident any of the shared interfaces—
HttpBodyorAsyncRead—tick off all the requirements someone might have. Maybe a blanket implementation for either trait could work/bridge some gaps in the interface?- Body isn't really a
@davidbarsky I mostly meant if there were plans to add the impl even though I used "instead of". I didn't mean removing any other API.
@abonander Ah, sorry about that; I misread what you said. Maybe? I'm not 100% sure how that could be implemented without needing specialization, but I might be missing something!
@davidbarsky how would specialization be necessary? There's only one possible impl,
Bodyisn't generic. Digging through the code it looks like it usesAsyncReadunderneath and then switches to producingBytesinproto::h1::io.Are there plans to migrate
BodytoAsyncReadinstead of being aStream<Item = Chunk>?
[..]
I mostly meant if there were plans to add the impl even though I used "instead of". I didn't mean removing any other API.No plans so far... Here's some reasons of the top of my head why not to:
- The
Bodycannot freely implementStreamandAsyncRead. In order to provideAsyncRead, it would need to add a slot to cache aChunk, in case theAsyncRead::poll_readbuffer wasn't big enough to copy the full thing. This would make the struct bigger and add another branch toStream::poll_next. - The
Streamimpl can include more specific errors. I suppose anAsyncReadcould just translate those tostd::io::ErrorKind::Other, though...
If there are good reasons to consider otherwise, we should open a new specific issue to discuss, ya?
- The
All the original "features" on master now use std::future, so I'm going to close this. Some tests and docs still need updating, thought.
Reacted by Linus Unnebäck, Grzegorz Szeliga, Pierre Brouca, Tux3, Boris Berman, Kat Marchán, Francesco Cogno and FeiReacted by Grzegorz Szeliga, Boris Berman, seungha-kim and Gabriele
With
std::future::Futurestabilizing in Rust 1.36, it is a goal to upgrade fromfutures@0.1tostd::future::Futurein the next breaking change (hyper@0.13).Status: