I'm going through the Tokio tutorial. I have this code example:
Set(cmd) => {
let mut db = db.lock().unwrap();
db.insert(cmd.key().to_string(), cmd.value().clone());
// Is the critical section active while we're constructing the Simple?
Frame::Simple("OK".to_string())
}
Which uses a blocking MutexGuard in an inner scope for mutating the db. Wouldn't the critical section be shorter if we do:
Set(cmd) => {
db.lock().unwrap().insert(cmd.key().to_string(), cmd.value().clone()); // Did CS end here?
Frame::Simple("OK".to_string())
}
The first version is preferred because what's intended here is something like: Hold ur horses while I send this Simple to the client because it is higher priority?
In this example CS is trivial yes. What I want to learn is that can I set a priority mechanism with blocking strategy? Is it an idiomatic way of expressing priorities? Or people reach out for executor configuration, because it's quite a blunt tool?
I do not think it is intended by the developer, really, more like they did not put more effort towards this piece.
Also, hopefully, the compiler eventually gets smart enough to reorder the accesses which unlock Mutex with accesses to locals (and Frame::Simple("OK".to_string()) at that). I do not know if it'll handle tokio's Mutex fine. It would also require some tuning or hints so that it tries to move .lock() down and unlock up instead of the reverse.
Thanks for the input. Can anyone suggest idiomatic ways for priority management in Tokio? I'm looking for something like what Embassy framework describes here: Embassy Book