Closed cod10129 closed 1 month ago
This works, but it seemed wrong to me when I saw it. There's an implementation with
getrandom
right there.
It doesn't really matter, this is a pseudorandom number generator, so it doesn't matter if the seed has cryptographic level strength. It's just that some seed is nice to have here. Unfortunately the thread::id()
and time tricks aren't available on WASM, hence the getrandom
implementation.
I would also rather keep fastrand
dependency free if possible.
The
#[cfg(target_pointer_width = "128")]
atlib.rs
line622
is generating a warning, which has been failing CI since May, after theunexpected_cfgs
lint was added in Rust 1.80.
This is tracked in #85
Unrelated but I also really like the cat logo.
Thanks! It was drawn by NebulousStar on Twitter.
Alright, fair points. Seeding with the time is often used, but does it also need the thread ID? Note the main thread is always ThreadId(1)
.
I would also rather keep
fastrand
dependency free if possible.
I was actually wondering if the dependency was the reason. getrandom
also pulls in cfg-if
and (on Unix) libc
. It is a nice cargo tree
to just see a self-contained fastrand
crate.
Note the main thread is always
ThreadId(1)
.
Keep in mind GLOBAL_RNG
is a thread-local variable, so it will be initialized with a different thread ID every time.
I was actually wondering if the dependency was the reason.
getrandom
also pulls incfg-if
and (on Unix)libc
. It is a nicecargo tree
to just see a self-containedfastrand
crate.
Agreed, this is my problem with getrandom
, in addition to the fact that it pulls libc
instead of rustix
on Linux.
The RNG is thread-local, but two different threads aren't initializing their RNGs at the same nanosecond. I went through the performance implications:
std::thread::CURRENT
Arc
(Thread.inner
)Arc
)Seems negligible, since there's also hashing and Instant::now
happening.
I'm thinking I'll just close this PR, unless there's anything you want to say?
The RNG is thread-local, but two different threads aren't initializing their RNGs at the same nanosecond.
This isn't guaranteed.
I'm thinking I'll just close this PR, unless there's anything you want to say?
Yeah, I'd agree with closing the PR.
Thanks anyways!
This PR makes the default random RNG seed always use
getrandom
. The original code looked like this:DefaultHasher
doesn't actually have any randomness in it, so you're just hashing the current time and thread ID to seed RNG. This works, but it seemed wrong to me when I saw it. There's an implementation withgetrandom
right there.A few other things I noticed: The
#[cfg(target_pointer_width = "128")]
atlib.rs
line622
is generating a warning, which has been failing CI since May, after theunexpected_cfgs
lint was added in Rust 1.80. Unrelated but I also really like the cat logo.