Is there a best practice/shining example out there of passing values from a non-UI thread to a UI thread in an Eclipse plugin application?
2 Answers
You could use Display.asyncExec()
To allow background threads to perform operations on objects belonging to the UI-thread, the methods
syncExec(Runnable runnable)
andasyncExec(Runnable runnable)
ofDisplay
are used.
These are the only methods inSWT
that can be called from any thread.
They allow a runnable to be executed by theUI-thread
, - either synchronously, causing the background thread to wait for the runnable to finish, - or asynchronously allowing the background thread to continue execution without waiting for the result.A runnable that is executed using
syncExec()
most closely matches the equivalent direct call to the UI operation because a Java method call always waits for the result before proceeding, just likesyncExec()
.
As illustrated by this thread:
I thought all those runnables or threads I give to
Display.sync
orasyncExec
are 'Threads
' and they get scheduled by the jvm or something along with the UI thread!
I never knew they are not considered the threads, but only pieces of code executed asynchronously by the UI thread!
This piece of code asynchronously executed by the UI thread might be a good place to access values (synchronized access) from other thread.
See "How to update a GUI from another thread in Java" as a practical example of passing a value to the UI thread.
(Note: the non-eclipse non-SWT way would have been, in Swing, by using a Swing Worker, as I mentioned a year ago)
-
Thanks. I got the syncExec part. I was wondering if there was a better/recommended way to get info from a real background thread than calling syncExec, scheduling the real bg thread from the run() method and waiting for a result to be available by polling and sleeping. For example, an I sync up the 2 processes with event handlers? (In my example, I'm waiting for network results, which CANNOT be called from the UI thread othwewise) – Jake Dec 04 '09 at 13:31
A little late getting into this one, but I would use a org.eclipse.ui.progress.UIJob.
When your non-UI thread has some information to send to the UI, it can spawn off a UIJob, that runs in a particular Display. Behind the scenes, asyncExec is used, but you get a lot of nice parts of the Jobs API along with it like a ProgressMonitor, job cancelation, rule scheduling, and join/waiting for other jobs.

- 28,387
- 9
- 92
- 148
-
similar to what I eventually did, outlined here: http://www.critical-masses.com/jakeofalltrades/displaying-progress-eclipse-ui-wwud – Jake Dec 08 '10 at 12:56