Community
Participate
Working Groups
I'm filing this bug as a result of discussion in bug 199915. I believe that the flexible hierarchy APIs would be easier and safer to implement if they were guaranteed to be invoked only on the UI thread. Currently this is already mostly the case, however since the interface definitions do not specify this, the implementers of these interfaces must assume that they need to be thread safe. As part of this request, I think IPresentationContext should have a new method: Display getDisplay(); This would provide easy access by the implementers to the Display object and thread.
Actually, this is not the case. A provider can be called in a non-UI thread in response to an event from a model proxy. I.e. A model proxy triggers updates in the thread that the model proxy reports deltas in. I'm not sure we want/need to change this for 3.4.
I'm sorry, I should have been more clear that this is an item for consideration past 3.4. I agree that it's too late to rock the boat on these APIs in 3.4. (In reply to comment #1) > Actually, this is not the case. A provider can be called in a non-UI thread in > response to an event from a model proxy. I.e. A model proxy triggers updates in > the thread that the model proxy reports deltas in. As part of this request, I think we should also consider making it mandatory that IModelProxyListeners be called on the UI thread, and that the viewer process the delta within the same dispatch (i.e. without using a WorkbenchJob as it does now). This would allow the model proxy to more accurately predict the state of the viewer in order to prevent race conditions in the proxy itself. I ran into this problem recently when fixing bugs related to a cache maintained in DSF's IElementContentProvider/IModelProxy implementation. In order for the cache to be synchronized with the viewer, in certain situations it needs to be reset at the same time as when the view contents are refreshed. However, since the viewer's model proxy listener schedules a job to process the proxy, there is a small window of time when the cache could be corrupted with stale data. Still, I think such API changes need time to be considered, and I'm willing to live with this theoretical race condition through 3.4.
Marking assigned for future consideration
After the flex viewer refactoring, we now have IModelProxy2 interface which has an initialize() method called on the UI thread. I also changed the viewer's delta listener implementation to process the deltas immediately if received on the UI thread.
