5 ms·
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
by tczMUFlmoNk 1y ago
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.
- Qwuke 1y agoYes, if you want a mature web framework that doesn't force you to use async then Rocket already exists, which is multithreaded and quite performant - and now allows you to use async if you want to. Feather seems fundamentally single threaded and requires more boilerplate for something pretty simple. So I'm not sure the claim about developer experience holds up to scrutiny here either.
- gfs 1y agoReading the latest stable documentation [0], it appears that you have to use async? [0]: https://rocket.rs/guide/v0.5/upgrading/#stable-and-async-support https://rocket.rs/guide/v0.5/upgrading/#stable-and-async-sup...
- deleted 1y ago[deleted]
- Qwuke 1y agoSorry, so you can use synchronous functions for writing middleware and routes, but the rocket core does use tokio. Not all async Rust webframeworks let you do away with async and futures entirely in your business logic.
- gfs 1y agoSo the caveat is you need to call `spawn_blocking` with synchronous functions. I see.
- Qwuke 1y agoWith a framework like Axum, yes, but with Rocket, no - you can just declare synchronous functions and pass them as a route handler, e.g.: https://github.com/Qwuke/recurse-ring/blob/main/src/main.rs#L185-L191 https://github.com/Qwuke/recurse-ring/blob/main/src/main.rs#... If you're averse to touching async fn's or tokio APIs _at all_, it's nice devex.
- cirego 1y agoI noticed the same thing. I would have expected an Arc<Mutex<…>> or something similar for safe concurrency. Not sure what value is delivered by a single threaded, blocking web server.
- koakuma-chan 1y agoThis framework does thread per connection, but all requests go into a global request queue, and when you call `listen`, it enters an infinite loop which pops requests from the queue and processes them synchronously (one by one).
- cirego 1y agoIt sounds like this framework is susceptible to head of line blocking. In my experience, that significantly reduces the utility of any applications written choosing this framework. What’s the benefit being delivered?
- koakuma-chan 1y agoNo benefit, this appears to be a student's pet project. The submitter has 179k karma and they aren't this framework's author. Either the submitter is unfamiliar with Rust and mistakenly thought this is a real deal or there's some kind of karma abuse/farming going on.
- steveklabnik 1y agoThis was posted by its author to /r/rust and then submitted here by someone because if a post does well over there, it often does well over here. That’s not “karma abuse”.
- rc00 1y ago> This was posted by its author to /r/rust and then submitted here by someone because if a post does well over there, it often does well over here. That’s not “karma abuse”. Except the submitter account in question is actually automating submissions from what looks like Lobsters (based on the timing and posting history). The account owner only seems to post non-automated comments to spam their product. This looks an awful lot like abuse. Or is abuse okay when you perceive it to be beneficial to Rust propaganda?
- ivanjermakov 1y agoSingle threaded web server? Is this a joke?
- 7bit 1y agoA single threaded Facebook server would have saved humanity.