| Thread-safety and org.eclipse.core.runtime.preferences [message #637976] |
Tue, 09 November 2010 13:37 |
 Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Implementers of the extension point org.eclipse.core.runtime.preferences
define a derivative of AbstractPreferenceInitializer that get's
automagically initialized. This is all fine for most use-cases, but it
becomes a source of real troubles, if you don't know under which
conditions (e.g. in which thread) the initializeDefaultPreferences()
will be invoked.
E.g. The normal interface functions of
org.eclipse.jface.preference.IPreferenceStore - which can be indirecly
invoked by e.g. a call to
RGB getColor(IPreferenceStore store, String name)
of the PreferenceConverter helper class does this and that causes
surprises, when the latter is invoked in a non-UI thread (e.g. in a
Swing thread).
It seems to me that there must somehow be a clarification, what a user
has to expect, in which thread his or her initializeDefaultPreferences()
function could be called, because quite often SWT resources are involved
in this function. It must be either guaranteed that this function is
called in the SWT thread or, at a minimum, user code must expect the
worst case and need to call Display.syncExec. The latter is potentially
sensitive to dead-locks, must the implementor of this methods has no
other chance, because at the end of the function call the required
default "values" must have been provided (this Display.asyncExec cannot
realize that).
Any ideas how this problem is typically solved as a workaround. Are
others also using Display.syncExec to ensure that initialization happens
in the SWT UI thread?
Thanks & Greetings from Bremen,
Daniel Krügler
|
|
|
Powered by
FUDForum. Page generated in 0.02299 seconds
] 
Search
Help
Register
Login
Home
