Concurrency Strategy is Unclear

[reem]

It appears to me that parallel connections block on handler.handle here https://github.com/seanmonstar/hyper/blob/master/src/server/mod.rs#L55.

This seems weird to me. I would much rather Handler: Clone, and for Handler to simply be copied for each request and handler.handle called in its own task. That way, downstream users of this library have maximum control of what concurrency forms they want.

If not, you will have to expose a stream of incoming requests to allow downstream users to decide on their own concurrency strategies.

[seanmonstar]

Should it be the case that the http server just spews out new tasks for all incoming requests?

What if the Handler trait received an 'incoming’ function, with a default implementation to stay single tasked?

From: Jonathan Reem
Sent: ‎Saturday‎, ‎September‎ ‎06‎, ‎2014 ‎11‎:‎58‎ ‎AM
To: seanmonstar/hyper

It appears to me that parallel connections block on handler.handle here https://github.com/seanmonstar/hyper/blob/master/src/server/mod.rs#L55.

This seems weird to me. I would much rather Handler: Clone, and for Handler to simply be copied for each request. That way, downstream users of this library have maximum control of what concurrency forms they want.

—
Reply to this email directly or view it on GitHub.

[reem]

I think the best solution would be to expose a stream of Request/Response pairs as an Iterator, much like TcpStream, and then registered handlers would just receive this stream and can decide on whatever concurrency strategy they want.

I think this is the most flexible approach we could take, especially considering that it's unlikely most users will interact with hyper directly so providing flexibility to frameworks is key.