Http::bind does not scale to uses where a Handle is needed

[brendanzab]

So, I have a ReverseProxy type that requires a Client in order to be constructed. But in order to do that I need to do the manual set up of the Tokio event loop, because constructing a Client requires access to the Handle, which I can't get when calling Http::bind.

fn run() -> hyper::Result<()> {
    // Set up the Tokio reactor core
    let mut core = Core::new()?;
    let handle = core.handle();

    // Set up a TCP socket to listen to
    let listen_addr = SocketAddr::new(Ipv4Addr::new(127, 0, 0, 1).into(), 8080);
    let listener = TcpListener::bind(&listen_addr, &handle)?;

    // Listen to incoming requests over TCP, and forward them to a new `ReverseProxy`
    let http = Http::new();
    let server = listener.incoming().for_each(|(socket, addr)| {
        let client = Client::new(&handle);
        let service = ReverseProxy::new(client, Some(addr.ip()));
        http.bind_connection(&handle, socket, addr, service);
        Ok(())
    });

    // Start our server on the reactor core
    core.run(server)?;

    Ok(())
}

This gets pretty horrific once I start needing the graceful shutdown behavior of Server::run_until, as shown by hyper-reverse-proxy/examples/extended.rs. I pretty much need to re-implement all of that stuff myself...

Is there a better way to go about this? Or could we have a Http::bind_with_handle which could allow us to pass a handle to our own reactor core into Hyper?

[P-E-Meunier]

Same here, exposing a handle is not enough: I'm running two HTTP servers on the same event loop (one http handling let's encrypt, and redirecting other requests to https), plus a pleingres database connection, and an SSH server.

I would be able to spawn the pleingres and SSH server using just the current handle, but not to run the two HTTP servers, because each wants its own event loop.

I'd be willing to write the two extra lines in my program to start the event loop myself, though.

[seanmonstar]

I've put this off for a while claiming that it will be solved in tokio-proto, but I'm now leaning towards may as well fix it in hyper, if a generic way appears in the future, no harm done. The proposal is in #1322.