tczMUFlmoNk
5 days 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
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
5 days ago
Yes, 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
5 days ago
Reading the latest stable documentation [0], it appears that you have to use async?
[0]: https://rocket.rs/guide/v0.5/upgrading/#stable-and-async-sup...
Qwuke
5 days ago
Sorry, 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
5 days ago
So the caveat is you need to call `spawn_blocking` with synchronous functions. I see.
Qwuke
5 days ago
With 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#...
If you're averse to touching async fn's or tokio APIs _at all_, it's nice devex.
user
5 days ago
cirego
5 days ago
I 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
5 days ago
This 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
5 days ago
It 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
5 days ago
No 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
4 days 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”.
rc00
4 days 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?
steveklabnik
4 days ago
> Or is abuse okay
I just don’t care about karma that much. The first 500 is the only that matters. I find it hard to say that submitting a story that people found valuable is “abuse.”
> when you perceive it to be beneficial to Rust propaganda?
I don’t think this project has a particularly good architecture, nor do I agree with its claims about async rust. I didn’t upvote this submission.
rc00
4 days ago
> and then submitted here by someone
> I just don’t care about karma that much. The first 500 is the only that matters. I find it hard to say that submitting a story that people found valuable is “abuse.”
The submitting account is automated and mostly non-deterministic. Forget the fake internet points and focus on the fact that there are accounts on this site that mostly exist to spam. Isn't the value of this site that humans curate what is posted? Or is automating submissions not a form of abuse? Good to know where your ethics are.
steveklabnik
4 days ago
> Isn't the value of this site that humans curate what is posted?
The value of this site is that interesting things get posted. Them being from a human is not inherently required. I do think that it's more likely to be the case when it comes from a human, but that's secondary.
Also, I would argue that upvoting is more important to curation than submission.
> Or is automating submissions not a form of abuse?
I do not believe it is inherently a form of abuse. The site guidelines do not prohibit automatic submissions, for example. If they did, then yeah, I'd say it's not a good thing to do.
ivanjermakov
5 days ago
Single threaded web server? Is this a joke?
7bit
5 days ago
A single threaded Facebook server would have saved humanity.