Comment by tczMUFlmoNk

The fact that a request can happily get a mutable reference to a shared context felt suspicious to me, so I ran a quick test, and it seems like the whole server is single-threaded:

    $ cat src/main.rs 
    use feather::{App, AppContext, MiddlewareResult, Request, Response};
    use std::{thread, time};

    fn main() {
        let mut app = App::new();
        app.get(
            "/",
            |_req: &mut Request, res: &mut Response, _ctx: &mut AppContext| {
                res.send_text("Hello, world!\n");
                thread::sleep(time::Duration::from_secs(2));
                MiddlewareResult::Next
            },
        );

        app.listen("127.0.0.1:3000");
    }

    $ cargo run -q &
    [1] 119407
    Feather Listening on : http://127.0.0.1:3000

    $ curl localhost:3000 & curl localhost:3000 & time wait -n && time wait -n
    [2] 119435
    [3] 119436
    Hello, world!
    [2]-  Done                    curl localhost:3000
    real 2.008s
    Hello, world!
    [3]+  Done                    curl localhost:3000
    real 2.001s

That is: when the request handler takes 2 seconds, and you fire two requests simultaneously, one of them returns in 2 seconds, but the other one takes 4 seconds, because it has to wait for the first request to finish before it can begin.

It feels like this has to be the behavior from the API, because if two threads run `ctx.get_mut_state::<T>()` to get a `&mut T` reference to the same state value, only one of those references is allowed to be live at once.

It doesn't quite seem fair to call this "designed for Rust’s performance and safety". One of the main goals of Rust is to facilitate safe concurrency. But this library just throws any hope of concurrency away altogether.