feat(server): allow !Send Servers

Until this commit, servers have required that `Service` and their
`Future` to be `Send`, since the server needs to spawn some internal
tasks to an executor, and by default, that is `tokio::spawn`, which
could be spawning to a threadpool. This was true even if the user were
certain there was no threadpool involved, and was instead using a
different single-threaded runtime, like
`tokio::runtime::current_thread`.

This changes makes all the server pieces generic over an `E`, which is
essentially `Executor<PrivateTypes<Server::Future>>`. There's a new set
of internal traits, `H2Exec` and `NewSvcExec`, which allow for the type
signature to only show the generics that the user is providing. The
traits cannot be implemented explicitly, but there are blanket
implementations for `E: Executor<SpecificType>`. If the user provides
their own executor, it simply needs to have a generic `impl<F>
Executor<F> for MyExec`. That impl can have bounds deciding whether to
require `F: Send`. If the executor does require `Send`, and the
`Service` futures are `!Send`, there will be compiler errors.

To prevent a breaking change, all the types that gained the `E` generic
have a default type set, which is the original `tokio::spawn` executor.

examples/README.md

@@ -21,6 +21,8 @@ parses it with serde and outputs the result.
 
 * [`send_file`](send_file.rs) - A server that sends back content of files using tokio_fs to read the files asynchronously.
 
+* [`single_threaded`](single_threaded.rs) - A server only running on 1 thread, so it can make use of `!Send` app state (like an `Rc` counter).
+
 * [`state`](state.rs) - A webserver showing basic state sharing among requests. A counter is shared, incremented for every request, and every response is sent the last count.
 
 * [`upgrades`](upgrades.rs) - A server and client demonstrating how to do HTTP upgrades (such as WebSockets or `CONNECT` tunneling).

examples/single_threaded.rs

@@ -0,0 +1,51 @@
+#![deny(warnings)]
+extern crate futures;
+extern crate hyper;
+extern crate pretty_env_logger;
+extern crate tokio;
+
+use std::cell::Cell;
+use std::rc::Rc;
+
+use hyper::{Body, Response, Server};
+use hyper::service::service_fn_ok;
+use hyper::rt::Future;
+use tokio::runtime::current_thread;
+
+fn main() {
+    pretty_env_logger::init();
+
+    let addr = ([127, 0, 0, 1], 3000).into();
+
+    // Using a !Send request counter is fine on 1 thread...
+    let counter = Rc::new(Cell::new(0));
+
+    let new_service = move || {
+        // For each connection, clone the counter to use in our service...
+        let cnt = counter.clone();
+
+        service_fn_ok(move |_| {
+            let prev = cnt.get();
+            cnt.set(prev + 1);
+            Response::new(Body::from(format!("Request count: {}", prev + 1)))
+        })
+    };
+
+    // Since the Server needs to spawn some background tasks, we needed
+    // to configure an Executor that can spawn !Send futures...
+    let exec = current_thread::TaskExecutor::current();
+
+    let server = Server::bind(&addr)
+        .executor(exec)
+        .serve(new_service)
+        .map_err(|e| eprintln!("server error: {}", e));
+
+    println!("Listening on http://{}", addr);
+
+    current_thread::Runtime::new()
+        .expect("rt new")
+        .spawn(server)
+        .run()
+        .expect("rt run");
+}
+