refactor(server): remove unneeded Send + Sync

[spinda]

Http and Server placed Send + Sync bounds on NewService implementations which
were not actually required given tokio's event loop model. Remove them to reduce
limitations on end users of hyper.

• The commit messages match the guidelines in https://github.com/hyperium/hyper/blob/master/CONTRIBUTING.md#git-commit-guidelines

[spinda]

Motivating scenario: I have a Service whose call method makes use of a RefCell, since the self parameter of call is forced to be an immutable reference and I need to mutate some shared state according to requests processed. RefCell does not have Send + Sync, however, so without this change I'd have to use something more costly like Arc, when internally hyper only executes call on the same thread as run anyway.

[seanmonstar]

Hey there, thanks for the PR!

The bounds there were actually on purpose, even though it may seem unnecessary at the moment. The goal has been that eventually the TcpServer in tokio-proto would be able to do all the hyper's Server can, and would use that. To do so, since the TcpServer can start listening on multiple threads, to prepare for the move, the Send + Sync bounds exist.

You can use a Service without those bounds if you manage a Core yourself, instead of using Http::bind.

[spinda]

Ah, I see. Would it make sense to have an explicitly single-threaded version of bind without these bounds, to implement the boilerplate of managing a Core directly? (which could for the moment call into the current path for bind under the hood, since it's not yet multithreaded)

[seanmonstar]

Possibly. I'm not sure what sort of API that would look like though.

[spinda]

Perhaps keep Server single-threaded, drop the bounds from it, and introduce a ParallelServer with Send + Sync equivalent to the current Server type? Then a bind_parallel method on Http which produces a ParallelServer.

[seanmonstar]

Sorry it took so long, I wasn't sure that this should be done, but I'm now in favor. Anyone wanting to use the multi-threaded server can do it themselves or use TcpServer. No need to have restrictions for people who don't want it.

Thanks!