|Displaying frequently changing lists of eObjects [message #1764976]
||Mon, 05 June 2017 10:03
| Emil Ra
Registered: June 2017
I have a question about the correct way of handling a constantly changing list of eObjects, which is displayed in a viewer. I've been dealing with this issue for a while now, that's why I'd like to ask for expert advice :)
In my model, some elements contain lists of other elements.
Those lists are displayed in a TreeViewer or TableViewer on the UI.
The lists' contents are changing (add/remove/modify) all the time, and with a high frequency - they are not modified via the UI.
Modifying the lists is trivial - updates are also reflected in the viewers, as provided by the EMF item providers.
The first issue I faced is that there is a memory leak when removing elements from the lists, because the item providers still hold references to the removed objects.
I read in another thread here that the correct thing to do in this case is either 1) to dispose the old item providers and create new ones (too much overhead, since there are lots of modifications), or 2) to clear the eAdapters() list of the removed eObject.
I went with 2), which reduced the number of leaks, but didn't stop them completely, and I was also seeing ConcurrentModificationExceptions relatively often.
The reason for this is that while the UI thread was iterating over the lists (updating the viewer triggered by EMF ViewerNotifications), I was modifying the list from another thread. I think that the leaks still happened, because some of the operations on the lists weren't executed due to internal safety checks in the lists.
A simple solution I did is to move the list modifications to the UI thread (Display.getDefault().syncExec()/asyncExec()).
This solved the issues, but it doesn't seem to be a correct solution - and firing off UI tasks for every list modification adds overhead.
Another option would be to add synchronization between the thread from which I'm modifying the list, and the UI thread (that would be in the EMF item provider code), but that doesn't seem to be ideal either.
Is there a better solution to solve the issues? What is the best practice for such a use-case?
Thank you very much in advance!
|Re: Displaying frequently changing lists of eObjects [message #1775513 is a reply to message #1775505]
||Tue, 31 October 2017 08:54
| Ed Willink
Registered: July 2009
I would use two helper activities to avoid arbitrary concurrency complexity. One background thread, one foreground runnable.
Any change to the list is realized by queueing a change request object to the background thread, that, if not already scheduled, is scheduled to run in 100ms. This provides a guard against thrashing for high rates of change.
When the background thread runs, it processes all list change requests to create a new list and an update request list. Once the background thread has exhausted its input queue, it schedules a foreground, UI thread runnable, to process the update request list, creating/destroying UI objects as appropriate. As much work as possible is performed by the background thread to minimize the UI thread costs.
Obviously the communication between source/background, background/foreground threads needs careful synchronization.
Powered by FUDForum
. Page generated in 0.02296 seconds