Re: [platform-ui-dev] Question regarding DelayedEventsProcessor
DelayedEventsProcessor is not API oft he plugin. So it is not designed to be called outside of the plugin. Inside the plugin it is only used in the IDEApplication / IDEWorkbenchAdvisor.
So DelayedEventsProcessor#openFile is *not* designed to be invoked from any thread .
From: <platform-ui-dev-bounces@xxxxxxxxxxx> on behalf of Mickael Istria <mistria@xxxxxxxxxx>
Reply-To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Date: Friday, 22. June 2018 at 08:51
To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Subject: Re: [platform-ui-dev] Question regarding DelayedEventsProcessor
First, before we get too much into details, is this or does it cause a problem in the end? If yes, please make sure there is a bug reported for it. If not, then I think it's more valuable to focus on the backlog ;)
On Thu, Jun 21, 2018 at 1:07 PM, Becker, Matthias <mailto:ma.becker@xxxxxxx> wrote:
When you look now into the implementation of DelayedEventsProcessor#openFile you see that the complete work is done inside a “display.asyncExec”. I wonder why this is done.
aynchExec puts the runnable at the end of the UI queue and executes the work in the UI thread. But we are currently in the UI Thread and we got called because no other stuff needs to be done in the UI queue. So I would say we don’t need that “asynchExec” here. Or do I overlook something?
Could it be that DelayedEventsProcessor#openFile is designed to be invoked from any thread and can run out of the UI Thread? I think it's actually a good practice to have most methods not requiring to run on UI Thread.
So IMO, unless it causes a bug, there is value in keeping it as it (as it allows to invoke method from any thread).