←back to thread

Unexpected productivity boost of Rust

(lubeno.dev)
517 points bkolobara | 1 comments | 27 Aug 25 15:48 UTC | HN request time: 0.217s | source
Show context
neandrake ◴[27 Aug 25 21:50 UTC] No.45045755[source]▶
Rust caught the lock being held across an await boundary, but without further context I'd hedge there's still a concurrency issue there if the solution was to release the lock before the await.

Presumably the lock is intended to be used for blocking until the commit is created, which would only be guaranteed after the await. Releasing the lock after submitting the transaction to the database but before getting confirmation that it completed successfully would probably result in further edge cases. I'm unfamiliar with rust's async, but is there a join/select that should be used to block, after which the lock should be unlocked?

replies(2): >>45046187 #>>45046198 #
1. lilyball ◴[27 Aug 25 22:37 UTC] No.45046198[source]▶
If you need to hold a lock across an await point, you can switch to an async-aware mutex. Both the futures crate and the tokio crate have implementations of async-aware mutexes. You usually only want this if you're holding it across an await point because they're more expensive than blocking mutexes (the other reason to use this is if you expect the mutex to be held for a significant amount of time, so an async-aware lock will allow other tasks to progress while waiting to take the lock).