-
Notifications
You must be signed in to change notification settings - Fork 18
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
Safe handler dictionary iteration #326
Comments
Relates to #96. @colebaileygit would this be something you would be willing to help with? FYI @federicobond @gruebel @toddbaert |
Thanks for reporting @colebaileygit, it's nice to have an existence proof for the thread-safety issues we knew were there. |
The _client_handlers dictionary allowed modifications during iteration without proper concurrency control. I added some reentrant locks to manage concurrent access to the _global_handlers and _client_handlers data structures. See open-feature#326 Signed-off-by: Federico Bond <federicobond@gmail.com>
I wrote a test that can reproduce the issue 100% of the time on my computer and implemented some locks to prevent concurrent access to the event handler dictionaries. See #329 |
There is still quite a lot of thread-safety work to be done with other methods, particularly in the |
The _client_handlers dictionary allowed modifications during iteration without proper concurrency control. I added some reentrant locks to manage concurrent access to the _global_handlers and _client_handlers data structures. See #326 Signed-off-by: Federico Bond <federicobond@gmail.com>
I think we can mark this particular issue as resolved. |
I got this stack trace while running tests. I imagine it is a very rare race condition:
Can we make the handler data object safe for multi-threading?
The text was updated successfully, but these errors were encountered: