Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for Mutex::new() as const fn #66806

Closed
elichai opened this issue Nov 27, 2019 · 7 comments
Closed

Tracking Issue for Mutex::new() as const fn #66806

elichai opened this issue Nov 27, 2019 · 7 comments
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@elichai
Copy link
Contributor

elichai commented Nov 27, 2019

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

@jonas-schievink jonas-schievink added A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 27, 2019
@CryZe
Copy link
Contributor

CryZe commented Nov 27, 2019

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.

@elichai
Copy link
Contributor Author

elichai commented Nov 27, 2019

@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

@Coder-256
Copy link
Contributor

This should include RwLock too, right?

@elichai
Copy link
Contributor Author

elichai commented Nov 27, 2019

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

@Mark-Simulacrum
Copy link
Member

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.

@jonas-schievink
Copy link
Contributor

This is still listed as part of #57563

@Darksonn
Copy link
Contributor

For those looking for the PR that stabilized this, it is #97791.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants