Concurrency Strategy is Unclear

[hyperium]

Concurrency Strategy is Unclear

[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.