Nostr notes by

Yet Another Performance Footgun in Rust - Multithreading Lock ...

2026-10-30T04:51:10Z

Yet Another Performance Footgun in Rust - Multithreading Lock Edition

It turns out that RAII can lead to performance "footguns", not just regarding memory, but also with multithreading locks.
The "holding a mutex longer than necessary" footgun.
It’s easy to fall into this trap :
{
let data = data.lock()
data.update(10)
// ...lots of other code...
}
Oops, the mutex remains locked for the entire duration of the scope, even though it only needed to be held until the final write to the data variable. This degrades performance because other threads are forced to wait longer than they should. The performance hit, latency and throughput, scales linearly with the amount of code executed after the last write, the longer that code takes to reach the end of the scope, the more severe the latency increase and throughput drop become.
This footgun appears frequently in real world code, as many developers write "vanilla" Rust without manually managing the lifetime of these locks. One might suggest calling drop explicitly or wrapping the logic in an inner scope, but neither is a robust or reliable solution. Why? Because both require manual awareness, in other words, they rely on the developer's skill to do so. By definition, a "footgun" is something that catches users off guard, often without them even realizing it.
So, what is the solution? As it turns out, "ASAP drop" (dropping as soon as possible) can resolve not only memory related footguns but also performance issues stemming from multithreading locks.
Visualization :
let data = data.lock().unwrap() // `data` becomes a `MutexGuard<T>`
data.update(10)
data.update(20)
// The compiler analyzes when the `MutexGuard<data>` is last used.
// If the code above represents the final access, the compiler automatically inserts an unlock operation immediately afterward.
// This allows other threads to take their turn without any unnecessary, prolonged waiting.
data.unlock() // Inserted by the compiler
As a further implementation guide, since read access is safe to perform from multiple threads, the unlock operation is inserted immediately after the final write, detected via &mut references, interior mutability, and raw mutable pointers (*mut). The final read access, using & and *const, does not extend the lifetime of the MutexGuard. This ensures that other threads get their turn as soon as possible, eliminating wasted time, resulting in low latency and high throughput right out of the box.
8 posts - 3 participants
Read full topic

https://internals.rust-lang.org/t/yet-another-performance-footgun-in-rust-multithreading-lock-edition/24726

#rust #footgun #mutexguard

#rss #feeds #linksharing #qwibbit

SAFETY comments - nomicon This, in an ongoing discussion on URLO, ...

2026-10-29T18:12:53Z

SAFETY comments - nomicon

This, in an ongoing discussion on URLO, really hit home for me too.
Jookia:
Looking at the random crates I have downloaded, sdl3-sys, sdl3-rs, parley, fontations, they all use unsafe without a SAFETY quite a lot. std is even guilty of it, but seems to follow the suggestions here more. I tend to learn by doing or reading other people's work so this is where a source of my confusion comes from.
I've also noticed that there are some excellent examples of SAFETY comments and many, very many, examples of unsafe with no comments.
While agreeing with the OP, I thought "I'll refer to the nomicon, that will contain great guidelines on how to add SAFETY comments to code ..." - oops!
The nomicon doesn't mention SAFETY comments once, nor safety-related lints
While it does include inline comments in the "implementing Vec" example - they don't match today's expectations for format or content
I'd like to suggest raising a PR to the nomicon to:
add a dedicated section 1.4 "Documenting & auditing unsafe code" covering how to write safety comments as well as the fundamental rustc & clippy lints
update the implementing Vec example to include exemplary safety documentation
Given that we should expect a significant increase in the amount of unsafe being written in the next year, I'd consider now to be the right time to get ahead of this and hopefully push towards a positive feedback loop with more of that code including good comments.
I'd be happy to work on this, but only if it has a chance of landing
2 posts - 2 participants
Read full topic

https://internals.rust-lang.org/t/safety-comments-nomicon/24721

#safetycomments #nomicon #vec #urlo #looking #documenting

#rss #feeds #linksharing #qwibbit

Attempting to clean up the feature activation syntax? Currently, ...

2026-10-29T14:04:24Z

Attempting to clean up the feature activation syntax?

Currently, a feature activation in the manifest can include:
"foo": activate the feature foo in the current package
"dep:foo": activate the optional dependency foo
"foo?/bar": if the optional dependency foo is activated, activate the feature bar within it
"foo/bar":
If foo is non-optional dependency, activate the feature "bar" within it
If foo is an optional dependency, activate it, activate a feature named foo if present, and activate the feature bar
On the command line with resolver = "2" or later,
-F foo: activate foo within any selected packages that have it
-F foo/bar
If foo is a dependency of a selected package, treat foo/bar like it was in a manifest
Else if foo is a workspace member, activate bar within it
Problems with this
It is hard to know what all these different forms are and their subtle meaning (e.g. I'm not sure that my summary is 100% accurate)
Feels weird that -F foo/bar might not just activate bar but could also be equivalent of -F foo,foo/bar
It is too easy to accidentally use "foo/bar" and pull in a dep and never realize it (Lint for suspicious optional dependency activation · Issue #17639 · rust-lang/cargo · GitHub)
Processing "foo/bar" requires knowledge of the full manifest to know what it translates to (which caused us problems with the path we were taking on RFC #3491 which cause it to be pulled from the 2024 edition at the last minute)
I've occasionally been confused that "foo?/bar" isn't "dep:foo?/bar" though from other perspectives, foo?/bar makes sense to me
Additional context
We are phasing out being able to refer directly to optional deps (RFC 3491)
I have some other ideas for activating more non-feature items, like dep: does for dependencies
So how should we clean this up?
3 posts - 2 participants
Read full topic

https://internals.rust-lang.org/t/attempting-to-clean-up-the-feature-activation-syntax/24718

#rss #feeds #linksharing #qwibbit