You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: dave-openstreetmap[at]earth.li [Submitted to the original trac issue database at 2.31pm, Saturday, 25th March 2006]
The threads that recieve responses from the server directly modify the lines Map in the applet. This map is also iterated through with a fail-fast iterator. We should probably do something to stop the concurrent access, like synchronising the accesses on the map. A good start would be to make the map private and encapsulate the accesses to it. We could then control all of the locking in one place.
I have written a patch that reduces the amount this happens, but it doesn't solve the problem completely.
The text was updated successfully, but these errors were encountered:
Author: immanuel.scholz[at]gmx.de [Added to the original trac issue at 5.53pm, Sunday, 26th March 2006]
I already ranted somewhere about this. This is the reason, why there are some Enumerations are still in place (which are not "fail fast" but "fail undefined" ;)
Reporter: dave-openstreetmap[at]earth.li
[Submitted to the original trac issue database at 2.31pm, Saturday, 25th March 2006]
The threads that recieve responses from the server directly modify the lines Map in the applet. This map is also iterated through with a fail-fast iterator. We should probably do something to stop the concurrent access, like synchronising the accesses on the map. A good start would be to make the map private and encapsulate the accesses to it. We could then control all of the locking in one place.
I have written a patch that reduces the amount this happens, but it doesn't solve the problem completely.
The text was updated successfully, but these errors were encountered: