-
Notifications
You must be signed in to change notification settings - Fork 47
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
Support racy initialization of an Executor's state #108
Conversation
@kettle11 can you test this out in a wasm environment with atomics enabled? This should fix the issue you were running into. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Rebase this on |
I'm not sure if we can relax the atomic orderings on the access or not. There's no strict ordering requirements, per se. The worst that happens if it's improperly ordered is it allocates a few extra states that are immediately deallocated. |
Yeah I think it's fine to only use |
Could we just use |
I know there is some weirdness around Let's merge this with |
Quick check against the benchmarks seems to show a (mostly) positive improvement over the use of
It may be even faster if we could use a |
That makes sense; we're basically doing what |
Should be ready to go. |
83c4c3b
to
14fd269
Compare
Fixes #89. Uses @notgull's suggestion of using a
AtomicPtr
with a racy initialization instead of aOnceCell
.For the addition of more
unsafe
, I added theclippy::undocumented_unsafe_blocks
lint at a warn, and fixed a few of the remaining open clippy issues (i.e.Waker::clone_from
already handling the case where they're equal).Removing
async_lock
as a dependency shouldn't be a SemVer breaking change.