-
Notifications
You must be signed in to change notification settings - Fork 432
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
Use UnsafeCell in ThreadRng #285
Conversation
This is actually a small PR, if you think away the commits it is made on top of.
So I think the API of |
Actually why There are a couple minor hiccups with using First, you must ensure Second, I think I suppose |
I was already wondering why the existing code was using I seems we can't make |
Good point about As I understand it, there is a "primary instance" of the |
Couldn't you use |
Thanks all for the comments. I will clean up this soon(ish).
Ah, nice! So I could use Still I think I'll go with |
@pitdicker you can rebase now |
f5cbc91
to
8ce871b
Compare
Rebased. |
The use of I think I'm happy with the PR as it stands and comments are positive, so merge if you think it's ready. |
I wondered if we should consider an
We cannot use We could make |
Check #579; we don't even need Yes I think we could make |
Very nice!
because the first permits simply borrowing the |
This is based on top of #281, but only the last commit is interesting. Also this PR is in no way mergeable, but I wanted to get your opinion if it even is sensible.
Using
UnsafeCell
instead ofRefCell
insideThreadRng
makes the performance overhead ofThreadRng
and theReseedingRng
wrapper in-between just about negligible.Compare:
The idea is that we currently use
RefCell
, and panic if a second mutable borrow insideThreadRng
occurs. I can't really think of a situations where that can happen, see the comment in the last commit. In that case it should also be safe to useUnsafeCell
directly, with less overhead. But I am not sure what happens during panics...