Community
Participate
Working Groups
There are currently many bugs against the problems view reporting missing markers or markers with blank columns, none of which have steps to reproduce. Having tried several different algorithms without success, I'm beginning to suspect a concurrency issue in core.resources. The scenario: - Thread 1 (say, the UI thread) needs to read markers. This could be triggered by the user opening a view (problems) or changing the selection criteria (changing the selected resource, open editor, or active filter). It also may be triggered by a resource change. - Thread 2 (say, a build) is changing markers. It is adding, removing, and changing markers. The restrictions: 1. Apparently, it is possible to change markers without holding a workspace lock. This means there is no way to lock the workspace against marker changes, or to ensure that thread 1 isn't reading markers while thread 2 is changing them. 2. When a resource delta is recieved, there is no way to tell if this delta is referring to changes that occurred before or after the last time thread 1 read markers. 3. IResource.findMarkers is not atomic. According to my discussion with John, it seems that when findMarkers returns a result that spans more than one file, the markers in file 1 may have been collected before a change and the markers in file 2 may have been collected afterward. So... if there is a threadsafe algorithm for responding to marker changes (where the filter criteria changes in one thread and marker deltas arrive in another), please describe it. Otherwise, please provide some means to do so. The current problems view algorithm works like this: 1. Whenever a marker delta or filter change occurs, schedule an update unless one is already scheduled. 2. When the time comes to update, lock the workspace. While locked, search the workspace for all markers matching the filter criteria and send the list to the UI thread. 3. When the list arrives in the UI thread, clear the contents of the table and replace it with the new list.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
