Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Too much too many

To respond to some of your comments.

Yes, the use of synchronous events is a design flaw in the workbench, due to the event storms they create. This is a well known problem of using the observer pattern with synchronous events (see the comment about the repeated diamond pattern here: https://en.wikipedia.org/wiki/Reactive_programming#Evaluation_models_of_reactive_programming ).

Doing things asynchronously is much better. Although events sent via asyncExec is a good quick fix to speed things up in the short-term, it is still possible to create patterns of listeners that trigger event storms. A better approach (long term) would be to use an algorithm that dirties things that need to be recomputed and then recomputes them in the correct order without visiting any node more than once. I describe the algorithm in more detail here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=490149 - it would also work for everything that has listeners, not just databinding.

So I agree with the general approach suggested for your patch.

However, your message, above, also discusses permitting listeners to be notified on threads other than the UI thread, and this I strongly disagree with. Doing all your notifications on the UI thread is cheap as long as the listeners never do anything expensive synchronously, and they never need to. If a listener needs to do anything nontrivial, it can just mark something as dirty and initiate a job that does the expensive part. By allowing multithreaded notifications, you'd need to protect all the observable data and listener lists with mutexes or synchronized blocks, which are SLOW and destroy your cache utilization.

The current implementation of the Eclipse databinding library is a perfect example of why multithreaded listeners are a bad idea. It's full of data races and it has terrible overhead due to the (unnecessary) synchronization to support multithreaded listeners. Up until very recently, the progress monitor system also had severe performance problems due to its multithreaded notifications, and much of the speed-up came from moving stuff to the UI thread and removing the unnecessary synchronization.

Let's not conflate asynchronous notifications (which are a good thing) with multithreaded notifications (which are bad).

​  - Stefan

Back to the top