-
-
Notifications
You must be signed in to change notification settings - Fork 59
Avoid race condition in timer cancellation. #661
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
base: main
Are you sure you want to change the base?
Conversation
From the CI log linked above:
|
What actually is the race condition? Is the loop is closing down in the top half of |
The honest truth is that I'm not 100% certain myself. My best guess is that the CFTimerHandle actually failed during construction, so the Python object existed enough to be an object, but not enough to be fully instantiated with a valid The fix I've proposed here accounts for the messy cleanup process; I'm not sure if, had this change been in place, we might have gotten a more complete report of the underlying problem that caused the timer to fail. |
Yes, that makes sense: if Could we prevent this by moving Or if that isn't possible for some reason, we could wrap the bottom half of |
It's not the value in
The issue is with the CFRunLoopRemoveTimer call, and the fact that
I'm not sure I follow what you're suggesting here.
Again, it's not |
As discussed in person: the stack trace shows that the crash is happening while iterating over Any exception from |
We saw an odd failure in a dependabot CI run; this test only failed on macOS-15 Python 3.14, and passed on a re-run. As far as I can make out, it's a very niche race condition that is almost impossible to reproduce programmatically.
PR Checklist: