-
Notifications
You must be signed in to change notification settings - Fork 535
fix(profiling): Race condition spawning multiple profiling threads #1676
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
fix(profiling): Race condition spawning multiple profiling threads #1676
Conversation
There is a race condition where multiple profiling threads may be spawned. Specifically, if `start_profiling` is called immediately after `stop_profiling`. This happens because `stop_profiling` does not immediately terminate the thread, instead the thread will check that the event was set and exit at the end of the current iteration. If `start_profiling` is called during the iteration, the event gets set again and the old thread will continue running. To fix this, a new event is created when a profiling thread starts so they can be terminated independently.
sentry_sdk/profiler.py
Outdated
# make sure to clear the event as we reuse the same event | ||
# over the lifetime of the scheduler | ||
self.event.clear() | ||
event = threading.Event() | ||
self.threads.put_nowait(event) |
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.
just nitpicking but could we possibly have a better name than threads
?
Maybe signify purpose, like termination_events/stop_events
or something since we use them to break the profiler loops?
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.
just a naming nitpick, feel free to keep/rename as you deem fit
This is fixing a mistake from #1676, and adding a sample at the start of the profile instead of waiting 1 interval before getting the first sample.
This is fixing a mistake from #1676, and adding a sample at the start of the profile instead of waiting 1 interval before getting the first sample.
There is a race condition where multiple profiling threads may be spawned. Specifically, if
start_profiling
is called immediately afterstop_profiling
. This happens becausestop_profiling
does not immediately terminate the thread, instead the thread will check that the event was set and exit at the end of the current iteration. Ifstart_profiling
is called during the iteration, the event gets set again and the old thread will continue running. To fix this, a new event is created when a profiling thread starts so they can be terminated independently.