Startup improvements #2089
Merged
Startup improvements #2089
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…h background task
…ture instead of Runnables and Futures
Android notifier sizes
Generated by 🚫 Danger |
YYChen01988
approved these changes
Oct 21, 2024
# Conflicts: # bugsnag-android-core/api/bugsnag-android-core.api # bugsnag-android-core/detekt-baseline.xml
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal
Improve the startup threading behavior of the SDK to reduce the chances of deadlocks & ANRs.
Design
Previously the SDK startup included several calls which moved work to a background thread, and then used
Future.get()to block until the work was complete. This was done to keep I/O operations (and similar) off the main thread, but introduced the cross-thread overheads without any direct benefit (all the cost of a thread, without actually doing anything in parallel).This PR introduces a new model based around a
Providerinterface, which is similar toFutureTaskin concept. The primary implementation isRunnableProviderwhich has a very primitive work-stealing ability to ensure thatProvidersdo not block each other (avoiding possible deadlocks where tasks are blocked waiting for tasks on the same queue) unless required. That is: aProviderwill typically try and "do" another providers work (unless that provider has already done, or is busy doing said work).As far as possible the new model does not block until the data from a
Provideris actually required by a non-provider (such as the NDK module, or a crash handler). This should allow better use of the threads available during startup.Testing
Modified the existing unit tests to handle the changes to the models.