Peer list concurrent access crash (fix #71) #81
Merged
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.
I had the same error as you had in bug #71.
Here is my analysis.
When we need to access and modify an ArrayList from two different threads, there are typically two solutions:
As
peers
variable is used asPeerListAdapter
backend, we must choose the second solution, and the thread must be the UI thread.Currently, wrong access to
peers
occur at two places:listener
,peerChanged(...)
modifiespeers
from outside the UI thread;refresh()
, theAbstractJniResults.putBlob(...)
method does the same.The comments on the
sort()
method suggests the problem already happened and has been workarounded:This kind of workaround avoids to crash, but can result in an incorrect display (a missing item for example).
The fix I propose consists in always accessing/modifying
peers
in the UI thread.It removes the need of the
handler
, therefreshing
variable and the customsort()
method.It also allows to sort and notify only when needed (when an item is added).