WIP: Handle upload enable change at startup using callbacks #790
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
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.
(Kotlin-only implementation for now).
This is an alternative to #786. It avoids the weird flow control by having the Rust core be completely in charge of what to do when the upload state changes (and fixes a bug where a deletion ping is sent on first run, since the startup logic for first run can be made slightly different).
However, it is fundamentally broken since it deadlocks. When the callback is called, it does things involving the global Glean singleton, and since the lock on that is already held, it stalls waiting for the lock. There might be ways of rewriting the FFI wrapper to drop the glean lock and then call the callback, but since the callback is a member of the Glean singleton, I couldn't find a way to do it.