Open LaoLittle opened 2 months ago
In light of #2949, would it be possible to use std::sync::OnceLock
instead?
In light of #2949, would it be possible to use
std::sync::OnceLock
instead?
yeah, if we can use rust 1.70
If we care about compiling on the 2024 edition the MSRV would be 1.82.
I mean it's nice to be ready and all but personally, I think this can be blocked until tracing
uses 1.70 as this would be effectively a temporary change.
I think this can be blocked until tracing uses 1.70 as this would be effectively a temporary change.
I'm ok with that
Hmm, IMO OnceCell is wrong, because it's not thread-safe (and static mut is thread safe if the inner type is Sync). We need to wait for OnceLock...
Hmm, IMO OnceCell is wrong, because it's not thread-safe.
The OnceCell
in this pr is once_cell::sync::OnceCell
, which is thread-safe.
It is true that OnceCell
in std is not thread-safe, though.
and static mut is thread safe if the inner type is Sync
But I think thread-safety of Sync
is only guaranteed with static (not static mut).
The
OnceCell
in this pr isonce_cell::sync::OnceCell
, which is thread-safe. It is true thatOnceCell
in std is not thread-safe, though.
Oops, though the std::cell::OnceCell was used, my bad :)
But I think thread-safety of
Sync
is only guaranteed with static (not static mut).
Yes, because with static mut you can mutate the inner type, losing the 'thread-safety' things you added in there :)
Edit: nevertheless this change looks good, lets get rid of the static mut
's!
Motivation
References to a
static mut
variable would become a hard error in rust 2024.Link
Issue
Solution
Use once_cell::sync::OnceCell to do the one-time global initialization.