223: Use llvm_asm! instead of asm! r=Amanieu a=Amanieu
`asm!` will be deprecated soon in preparation for the new `asm!` macro, so switch to using `llvm_asm!` instead.
cc https://github.com/rust-lang/rfcs/pull/2843
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
219: Remove the lazy_static dependency r=Amanieu a=CryZe
I noticed there's a few things I missed in my previous PR.
1. lazy_static is not necessary anymore. We can just use the new const constructor functions instead.
2. The README still mentions lazy_static.
Co-authored-by: Christopher Serr <christopher.serr@gmail.com>
217: Implement Support for creating the locking primitives in a const context on stable Rust r=Amanieu a=CryZe
This adds a new constructor `const_new` to lock_api's mutexes, reentrant mutexes and RwLocks that allows creating them in a constant context on stable Rust by manually passing in the underlying raw mutex / rwlock.
Additionally, various helper functions are being added to parking_lot that allow creating mutexes, reentrant mutexes, fair mutexes and RwLocks in constant contexts on stable Rust.
Co-authored-by: Christopher Serr <christopher.serr@gmail.com>
This adds various helper functions to `parking_lot` that allow creating
parking_lot's mutexes, reentrant mutexes, fair mutexes and RwLocks in
constant contexts on stable Rust.
This new constructor allows creating mutexes, reentrant mutexes and
RwLocks in a constant context on stable Rust by manually passing in the
underlying raw mutex / rwlock.
204: Create API for mutex that is always fair r=Amanieu a=paulocsanz
Fixes#76. I don't know if there is interest in having a API for a Mutex that is always fair, but solving it at the type level seems better than requiring a state for each mutex. Fairness sometimes is required, so making type level assurances so another dev can't screw up may solve a bunch of problems, it's probably already being done by people that need it since it's just a thin wrapper.
This implements a `FairMutex` and it's `RawFairMutex`. This could be done for RwLock too if there is interest.
Idk if the tests are required since it's literally calling something already tested, but I just copied the files and made it compile. I had to remove the Condvar test, since Condvar assumes it's a MutexGuard, and doesn't accept a FairMutexGuard.
Co-authored-by: Paulo <paulosanz@poli.ufrj.br>
203: fix: not panic in destructor r=Amanieu a=zhangli-pear
`release_resource` should not panic. Because `with_thread_data` may return a `ThreadData` on the stack, and it's empty.
Co-authored-by: zhangli.pear <zhangli.pear@bytedance.com>
Noah