Rust's Sneaky Deadlock With `if let` Blocks
brooksblog.bearblog.dev
Rust's Sneaky Deadlock With `if let` Blocks
1–10 of 85 posts
Re: Rust's Sneaky Deadlock With `if let` Blocks
#2This is why pthread_mutex_lock() and pthread_mutex_unlock() will always be kings - it is clear when things are locked and when they are unlocked. Nobody needs to write articles warning you about pthread_mutex being taken randomly by syntactic sugar and not released till a magic later time due to the same sugar. Ditto for RWlock/XYZloc/ABClock/etc...
Re: Rust's Sneaky Deadlock With `if let` Blocks
#3This is why pthread_mutex_lock() and pthread_mutex_unlock() will always be kings - it is clear when things are locked and when they are unlocked. Nobody needs to write articles warning you about pthread_mutex being taken randomly by syntactic sugar and not released till a magic later time due to the same sugar. Ditto for RWlock/XYZloc/ABClock/etc...
I see it as a consequence of Rust being too liberal with additions to the language. It's hard to maintain some of these guarantees in the presence of certain syntactic forms. This happens in all languages.
It is a little hilarious to see a rustaceon write:
> and you can sus out if a program is going to cause a deadlock by just making sure you aren't acquiring multiple simultaneous locks.
Ah.. not a problem! You just have to not ever have the problem. Then, of course at the opposite end of the article:
> I wrote this block because this has specifically bitten different Rust crates in the wasmCloud project multiple times
:D
Re: Rust's Sneaky Deadlock With `if let` Blocks
#4This is why pthread_mutex_lock() and pthread_mutex_unlock() will always be kings - it is clear when things are locked and when they are unlocked. Nobody needs to write articles warning you about pthread_mutex being taken randomly by syntactic sugar and not released till a magic later time due to the same sugar. Ditto for RWlock/XYZloc/ABClock/etc...
[deleted]
Re: Rust's Sneaky Deadlock With `if let` Blocks
#5Happy to be corrected, but from what I gathered RWLock should mostly be avoided in favour of a simple Mutex unless you have a very read-heavy usecase and even then the performances are subpar compared to mutex.
Re: Rust's Sneaky Deadlock With `if let` Blocks
#6This is why pthread_mutex_lock() and pthread_mutex_unlock() will always be kings - it is clear when things are locked and when they are unlocked. Nobody needs to write articles warning you about pthread_mutex being taken randomly by syntactic sugar and not released till a magic later time due to the same sugar. Ditto for RWlock/XYZloc/ABClock/etc...
I see it as a consequence of Rust being too liberal with additions to the language. It's hard to maintain some of these guarantees in the presence of certain syntactic forms. This happens in all languages. It is a little hilarious to see a rustaceon write: > and you can sus out if a program is going to cause a deadlock by just making sure you aren't acquiring multiple simultaneous locks. Ah.. not a problem! You just…
[deleted]
Re: Rust's Sneaky Deadlock With `if let` Blocks
#7This is why pthread_mutex_lock() and pthread_mutex_unlock() will always be kings - it is clear when things are locked and when they are unlocked. Nobody needs to write articles warning you about pthread_mutex being taken randomly by syntactic sugar and not released till a magic later time due to the same sugar. Ditto for RWlock/XYZloc/ABClock/etc...
In rust, this is y=x.lock(), and later drop(y) or just end the scope block.
Sugary syntax is always an issue when side effects matter.
Having said that, I adore procedural code in general, but it does make ownership a fun mental exercise.
Re: Rust's Sneaky Deadlock With `if let` Blocks
#8This is why pthread_mutex_lock() and pthread_mutex_unlock() will always be kings - it is clear when things are locked and when they are unlocked. Nobody needs to write articles warning you about pthread_mutex being taken randomly by syntactic sugar and not released till a magic later time due to the same sugar. Ditto for RWlock/XYZloc/ABClock/etc...
There are however many PRs about people ignoring the return values of pthread_mutex_lock(), or missing an unlock on one route through a function.
Re: Rust's Sneaky Deadlock With `if let` Blocks
#9This is why pthread_mutex_lock() and pthread_mutex_unlock() will always be kings - it is clear when things are locked and when they are unlocked. Nobody needs to write articles warning you about pthread_mutex being taken randomly by syntactic sugar and not released till a magic later time due to the same sugar. Ditto for RWlock/XYZloc/ABClock/etc...
I see it as a consequence of Rust being too liberal with additions to the language. It's hard to maintain some of these guarantees in the presence of certain syntactic forms. This happens in all languages. It is a little hilarious to see a rustaceon write: > and you can sus out if a program is going to cause a deadlock by just making sure you aren't acquiring multiple simultaneous locks. Ah.. not a problem! You just…
The issue here isn't new features at all.
`if let` is more or less syntax sugar for `match`.
And match behaves like that, too and has been in rust since 1.0.
That match did behaves like that is due to some old, you could say legacy, reasons and had been criticized even in the early rust 1.x days.
But changing a behavior which subtle change when locks are released is not something you can easily fix with a rust edition so we are pretty much stuck with it.
Re: Rust's Sneaky Deadlock With `if let` Blocks
#10Happy to be corrected, but from what I gathered RWLock should mostly be avoided in favour of a simple Mutex unless you have a very read-heavy usecase and even then the performances are subpar compared to mutex.
maybe but that is unrelated to the distilled problem shown in the blog and RWLocks are not the only way this can bite you
but it's also behavior for rust match-like statements in general so nothing new nor specific to if let