Hyper: Future-based API

[DemiMarie]

This is a feature request for a future based API. Futures allow much easier handling of asynchronous computations with zero run-time overhead. They compile to almost the same state machine that one would write by hand.

[gsquire]

There is work being done to integrate tokio into hyper on this branch already it looks like: https://github.com/hyperium/hyper/tree/tokio

[zimond]

alert: I am keeping an eye on tokio branch and as far as I can say, the branch is broken and could not even compile. So if you want to try tokio-hyper (like me) try a fork

[DemiMarie]

Is there any activity on the tokio branch?

On Oct 19, 2016 03:38, "Zimon Dai" [email protected] wrote:

alert: I am keeping an eye on tokio branch and as far as I can say, the
branch is broken and could not even compile. So if you want to try
tokio-hyper (like me) try a fork

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hyperium/hyper/issues/934#issuecomment-254736081, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGGWB9jBytkncIpi4hek-Sp5bsMJ5YPRks5q1ckDgaJpZM4KW-a6
.

[seanmonstar]

I work on the branch as time permits. The client example works today, though plenty other bits do not.

[zimond]

@seanmonstar what is pretty_env_logger in tokio branch?

[seanmonstar]

Oh right. That's a local crate I have that works just like env_logger, but adds colors and padding to module paths. Perhaps I should publish it, but it's not hard to just comment that out. It should just be a dev-dependency.

[daogangtang]

I can run it now. Hope to reach the initial workable version quickly. :) Including request body processing.

[seanmonstar]

Just pushed to the branch again. It should handle request and response bodies now. Keep-alive partly works, as long as there was no response body. This is due to a bug in tokio-proto, should be fixed soon enough.

[daogangtang]

Thank you. Is it suitable to integrate tokio branch to upper web framework level now? Such as https://github.com/sappworks/sapper

[zimond]

@seanmonstar The latest commit is still breaking. If I set server response.body to something larger than a slice(4096), hyper will panic on assertion of self.available() > data.len() in src/http/buffer.rs

[seanmonstar]

@daiheitan Indeed! It doesn't yet handle back pressure, which is what those asserts are there for at the moment. Still have work to do!

@daogangtang The API won't change much, I don't think. The Response type could have some methods changed, the current "builder" style methods are just a test. There will likely still be bugs/panics, but if that doesn't scare you, you can try integrating :) It'd probably help actually, to determine if the Request/Response methods are adequate.

[zimond]

Another question: If I want to curl download something using tokio-curl, a handle to tokio-core event loop is needed. Any ideas how to get a handle in a NewService implementation?

[seanmonstar]

@daiheitan The Service and NewService thing are likely to see some refinement. I'd ask in the tokio gitter channel.

[zimond]

Fine, I asked in tokio gitter channel. Would it be possible that hyper provide a new trait which inherit NewService with an API like new_service_with_handle or something? Just a rough thought.

[carllerche]

The issue is essentially about being able to reuse the same reactor core that hyper is using. The best way to do this IMO is for hyper to have a way to initialize w/ a provided Handle. This would allow a third party to manage the reactor loop and libs are then able to run on any loop instead of every lib owning their own lib.

[seanmonstar]

@daiheitan The tokio branch has been updated, with a change in API. You can pass a tokio Handle to server.handle(new_service, handle), and the Server will attach itself to that core. Running the core is up to you then.

There is also server.standalone(new_service), which manages the Core internally.

[zimond]

@seanmonstar thanks!

[daogangtang]

nice

[dimbleby]

This sounds great.

Do you have any view on a likely timetable for getting this to a point where it can be released? Is there anything that the rest of us can do to help?

[seanmonstar]

@dimbleby I don't have a timetable. As a baseline, since it depends on tokio-proto, it is blocked on that reaching a release (likely 0.1). Besides that, there are some things that need to be done. I really need to break them out into issues, describing what to do that would help someone get into it, but here's a quick list:

• Writing of chunked bodies is missing the writing of the final zero chunk, 0\r\n\r\n, when the http::Conn receives the end of the body stream. (This doesn't affect reading chunked streams, just writing them).
• Writing of bodies does not handle backpressure. If the body stream sends chunks faster than the tcp socket is writable, it will panic once the internal buffer is full. This should instead check if it can fit the current chunk, and if not, stash it and return Async::NotReady.
• The client doesn't really handle keep-alive/connection pooling. The design of this is something that tokio-proto/tokio-service wants to help with.

[scottlamb]

Do you have plans to broaden the definition of Chunk? Or would you be open to discussing doing so, here or in a new issue? It's currently this:

/// A piece of a message body.
pub struct Chunk(Vec<u8>);

I'd love for it to be something that lets me avoid copying into a temporary vector in favor of using a &[u8] I already have. (My project has a few cases where this would be useful; I'd be happy to describe them if desired.)

One practical approach might be to use an enum based on the owning_ref crate:

/// A piece of a message body.
pub enum Chunk {
    Static(&'static [u8]),
    Vec(owning_ref::VecRef<[u8]>),
    Box(owning_ref::BoxRef<[u8]>),
    Rc(owning_ref::RcRef<[u8]>),
    Arc(owning_ref::ArcRef<[u8]>),
}

which I think would let you do anything without copying, although some things would need a reference count or indirection (extra memory allocation / pointer to chase) per chunk.

A couple other approaches that I considered but don't think are actually possible: (1) some way of exposing a 'lifetime parameter associated with a particular request, (2) some way of associating a parameterized Context (or owner) with each Response or Body + having each chunk take a Fn(&Context) -> [u8].

[seanmonstar]

@scottlamb Indeed, I would like to broaden what is an http::Chunk. It is currently super basic, just wrapping a Vec<u8>, but I would like to add optimizations to it. I opened https://github.com/hyperium/hyper/issues/953 for that discussion.

[clemensw]

tokio branch wouldn't build for me. Updating to the available crate-based dependencies seems to fix the issue. (#963)

[steveklabnik]

This branch was just merged, it seems?

[seanmonstar]

Ah, yes! The tokio branch has been merged (and squashed some) into master. So I'll close this, and any specific things can be individual issues.