Why and when does trillium serialize calls?

[quixoticaxis]

Hello.
I'm currently getting started with Trillium and I've written the following code:

use std::time::Duration;

use log::LevelFilter;
use simple_logger::SimpleLogger;
use trillium::{Conn, Status};
use trillium_async_std::Stopper;
use trillium_logger::Logger;
use trillium_router::Router;

fn main() {
    SimpleLogger::new()
        .with_level(LevelFilter::Debug)
        .init()
        .expect("The logger should be able to be initialized without an issue.");

    let stopper = Stopper::new();

    set_stopper_to_handle_ctrlc(stopper.clone());

    trillium_async_std::config()
        .with_host("127.0.0.1")
        .with_port(7878)
        .with_stopper(stopper)
        .run((
            Logger::new(),
            Router::new()
                .get("/", serve_default)
                .get("/sleep", serve_sleep),
        ))
}

async fn serve_default(connection_state: Conn) -> Conn {
    log::debug!("Serving the default page");

    connection_state
        .with_body("Default page")
        .with_status(Status::Ok)
}

async fn serve_sleep(connection_state: Conn) -> Conn {
    log::debug!("Serving the sleep page");

    trillium_async_std::async_std::task::sleep(Duration::from_secs(10)).await;

    connection_state
        .with_body("It was a great nap")
        .with_status(Status::Ok)
}

fn set_stopper_to_handle_ctrlc(stopper: Stopper) {
    ctrlc::set_handler(move || {
        log::debug!("Initiating the stopping procedures");
        stopper.stop()
    })
    .expect("The handler should just work.")
}

When I'm accessing 127.0.0.1:7878/sleep concurrently in two tabs of my browser, the requests are served sequentially. When I'm accessing the same page from two different browsers, the requests are served in parallel.
The browser most probably does not serialize the calls, because the same code implemented with my handcrafted http server over TcpListener doesn't exhibit the same behavior (every request is being served concurrently).
Could someone, please, point out what am I missing here?

[jbr]

If your handcrafted http server does not support http/1.1 keepalive, that would explain the difference. Your browser is reusing the same tcp connection. How are you making the request in the browser? Try it with curl in the terminal to see that two separate requests on different tcp connections do not block each other

[jbr]

Additionally, you should not need to register your own control-c listener or configure the stopper. That is handled by the async-std runtime adapter.

[quixoticaxis]

If your handcrafted http server does not support http/1.1 keepalive, that would explain the difference. Your browser is reusing the same tcp connection. How are you making the request in the browser? Try it with curl in the terminal to see that two separate requests on different tcp connections do not block each other

Thank you for the tip, you're right, the browser issues requests with Connection: keep-alive, and my toy server ignores it.

[quixoticaxis]

Additionally, you should not need to register your own control-c listener or configure the stopper. That is handled by the async-std runtime adapter.

Yes, I assumed so initially (followed the docs), but for me it does not seem to work.
When I don't set the custom handler, I get

error: process didn't exit successfully: target\debug\trillium-fun.exe (exit code: 0xc000013a, STATUS_CONTROL_C_EXIT)`.

With the custom handler set to use the Stopper, the code from my initial post works fine with the output of

2022-04-03T17:45:41.212Z INFO [trillium_server_common::config_ext] waiting for 1 open connection to close
2022-04-03T17:45:41.212Z DEBUG [trillium_server_common::config_ext] closing connection
2022-04-03T17:45:41.212Z INFO [trillium_server_common::config_ext] all done!

I'm running the code on Windows if this matters, I can check on Linux a bit later. Could this be a bug?

[quixoticaxis]

Yeah, Ctrl-C handling works on Linux, but fails on Windows. I'll create an issue.

[jbr]

Thanks! I punted on a lot of windows-specific things because I don't have a local windows machine. It's not that hard to spin up a cloud instance, though, so please do open an issue any time you discover things that don't work as expected on windows!