Scoped threads from Crossbeam (and, soon, the standard library), statics and Arcing bigger structures are all options for non-async threaded contexts; for async, the counterpart of scoped threads is to introduce lifetimes to futures, statics could work but aren't always applicable, and lumping things into bigger structures is universal
#Most performant way of using AtomicBools in asynchronous contexts
11 messages · Page 1 of 1 (latest)
(also, there's no good reason to ever use Mutex<bool> or RwLock<bool>, but I hold that to be self-evident)
yeah, that should work if global state makes sense in your case
mentioned that as a second option for non-async code, but I'm not really seeing how it would apply to async
code that uses global state is very often lower-level than async abstractions
but in the relatively rare situations when it's not, feel free to use statics
they have zero overhead whatsoever (none on top of the atomicity, of course)
it's the thread-locals that have a bit of an overhead with the current implementation
but that's in the process of being reworked and fixed
even now, it often yields a sizeable win over synchronization when you know that a single thread will ever access the thread-local
but since your state is program-wide, they don't really work here