Community
Participate
Working Groups
From bug 303926 comment #3: > I still have one remaining concern about the integrity of the model data. > While there are (add/remove) deltas pending to be fired to the viewer, the > viewer may come and retrieve data from the model. If this happens then the > delta will operate in the viewer on data based on a model that is different > than when the delta was created.... leading to corrupted data in the viewer. > I'm not sure if there's much we can do about this actually, because the viewer > updates themselves are posted to the viewer with some skid, so even if we were > to synchronized updates with deltas in the content provider we may not solve > the problem. I think I'll just open a separate bug to investigate this issue > by first writing some tests to reproduce, then work on a solution. After a couple of hours of work I managed to write a test case to reproduce this problem. I added this test case to the unit tests as org.eclipe.debug.tests.viewer.model.UpdateTests.testContentPlusAddRemoveUpdateRaceConditionsElement, though it's currently disabled.
Created attachment 160351 [details] Suggested fix.
The suggested fix is rather simple. It would avoid using a workbench job in the viewer updates, if the IViewerUpdate.done() is called in the display thread in the first place. This would allow the content provider to more accurately synchronize the updates being completed with add/remove deltas being fired. On the down-side this patch causes some of the tests to fail on redundant updates from the viewer. I.e. when the viewer receives updates from the content provider immediately (synchronously) as the test model completes them, the viewer seems to generates some updates twice. Also, I'm not clear on the use of the scheduling rule in the viewer update job. It seems that the viewer updates will be synchronized by the display anyway, so the scheduling rule is redundant.
I retried this fix with 3.8M5. It fixes the unit tests, but it now trips another test: StateTests.testPreserveExpandedOnMultiLevelContent(). The problem is that making the update write to viewer faster, breaks some of the coalescing optimization. The tradeoff is correctness vs. performance so we may want to make this fix anyway. Will investigate further still.
I found a way to fix this issue without tripping other other tests: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=4c1874fbdca333cadccd1271d06796c0ee5fb1c7
Oops I committed an incomplete fix. Here's the rest: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=c5f4e83dcce152ab653d22968e4c60ddf30896d6
