-
-
Notifications
You must be signed in to change notification settings - Fork 306
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
Create the profiling envelope item on a background thread #3893
Comments
It does make sense to consider for the new implementation, definitely. For legacy profiling, I think it should be fine to move things to a bg thread once we have the transaction created by the tracer. There may be a few accesses of the tracer via the transaction from profiler code, but those could be replaced with parameters in the profiling methods/functions that are called so the values can be captured before offloading to the bg thread, risking deallocation. |
Description
Currently, the tracer creates the profile envelope item, which calls slicing the profiling data on the calling thread of
SentryTracer.finishInternal
heresentry-cocoa/Sources/Sentry/SentryTracer.m
Lines 627 to 644 in c02bb1f
When the profile lasts for a few seconds, this could noticeably block the main thread. With #3826 the captureTransaction in the hub already happens on a background thread. Moving
createProfilingEnvelopeItemForTransaction
to a background thread is a bit trickier, because if the tracer gets deallocated in the meantime, it might remove the profiling payload in dealloc:sentry-cocoa/Sources/Sentry/SentryTracer.m
Lines 208 to 215 in c02bb1f
While we can somehow fix this problem with the current solution, continuous profiling (#3555) will change our current approach, and the solution could get outdated. @armcknight, does it make sense to consider this point while moving towards continuous profiling (#3555)?
The text was updated successfully, but these errors were encountered: