Update InputStreamReader and OutputStreamReader to use their lock instead of themselves as the encoder/decoder lock. #2394
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.
Update InputStreamReader and OutputStreamReader to use their lock instead of themselves as the encoder/decoder lock.
Stream decoder will continue to take in a lock via the public factory methods. The internal initializers will still call super with the lock. To ensure the initializers will not be called, they will be made private.
It’s up to the InputStreamReader to pass in the correct lock instead of itself. So to fix this, the lock created by the InputStreamReader’s superclass (Reader) at construction time will be passed in instead.
Did the same thing for the OutputStreamWriter. (StreamEncoder constructors were already private)
This was causing a retain cycle in iOS.
Additionally, the reader and decoder were using different objects as their lock which may lead to some contention