Tracking Issue for `Mutex::new()` as const fn
elichai opened this issue · 7 comments
Hi,
I think being able to do
static mut GLOBAL_LOCK: Mutex<Type> = Mutex::new(Type::new())
Is a very important feature, right now you have to do weird jumps with Option/MaybeUninit and Once to then return a &'static Mutex<T>.
In practice, the missing pieces here are: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/mutex.rs#L24 and #57349
alexcrichton Pointed out here #66823 (comment) that this also requires Box. so that's another missing piece in cost fn for these to be usable in const fn's
I opened this Issue as part of: #57563
This would mean that Rust needs to use its own Mutex implementation (such as via parking_lot) as in general the mutexes provided via the OS can not be made const. It may be possible to do so on some OS's but that can't be generalized to all.
It probably makes more sense to make sure you can use parking_lot's Mutex::new as a const fn on stable Rust before trying to do this for std.
@CryZe Makes some sense that we can't ask the OS for a mutex in compile time.
but what we might be able to do, is maybe not init() the mutex when calling new(). but instead using Once to only initialize it on the first lock.
altough the AtomicBool overhead here might not be worth it
This should include RwLock too, right?
Looking at the code from my phone Rwlock looks already doable, and I don't quite get why it's on the heap.
I'll open the laptop soon and experiment with it
Closing as this isn't really viable to do today (we need to box the system primitives) and isn't likely to get forgotten (i.e., is trivial to implement and widely desirable) once we get something like parking_lot merged.
This is still listed as part of #57563