-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Mild race condition in secp256k1_context_preallocated_create #351
Comments
Just want to note that this is only for the fuzzing configuration |
Right, this just seems like "it could be more performant", not a specific bug, if I'm reading your description correctly, which isn't super relevant given its only used in fuzzing and presumably after initial startup things are "warm" and just stay DONE. |
Ah, missed that it's only in fuzzing. Not looking immediately suspicious could have some benefit for reviewers too but if nobody wants to bother feel free to close. |
We could add a comment, I guess? But, really, std should expose Once even if we don't have the ability to park a thread - the code here is basically the same as the std Once, with the only difference being that we don't park threads and instead busy-loop to avoid using std. |
|
Yes, that's my point, it does the same thing plus parks threads (with relevant tracking to wake them up again). |
The code difference is so large that I'm not sure it'd be reasonable to abstract. And I generally love abstractions. Anyway I think just changing |
I agree with changing Philosophically I agree with Matt that "it doesn't matter" and also that it's somehow |
Possible scenario:
HAVE_PREALLOCATED_CONTEXT
DONE
WORKING
WORKING
DONE
againIn this scenario C needlessly waited for A even though the context was initialized. I suggest to use compare exchange to avoid erroneous swapping in the first place.
There's also
break
missing so B always makes one more iteration of the loop and may even ironically become thread C.The text was updated successfully, but these errors were encountered: