Description Camille Letavernier 2015-11-10 08:07:04 EST

All diagrams call the following snippet in their Activator#start method:

> CustomDiagramPreferenceInitializer diagramPreferenceInitializer = new CustomDiagramPreferenceInitializer();
> diagramPreferenceInitializer.initializeDefaultPreferences();

This eventually leads to the initialization of the GMF Appearance preference page, which uses a Display.syncExec() to define a Font.

Since the Properties View Configuration can be initialized in a Worker thread, the following steps typically happen when a generated Papyrus Diagram also declares a Properties View configuration:

- UI: Open the PropertiesView preference pages
- UI: PropertiesView's Activator#start in the UI Thread
-- UI: Starts a background Job to load properties view configurations and keep going
--- Worker: The background Job starts contributing plug-ins (e.g. Sequence Diagram) in a Worker Thread
--- Worker: SequenceDiagram initializes its preferences
--- Worker: The preferences eventually delegate to GMF's Appearance PreferencePage, which results in Display.syncExec()
-- UI: Waits for the PropertiesView configurations to be loaded to display the preference pages

So we have a deadlock between the Diagram's Activator waiting for the UI Thread, and the UI Preference Pages waiting for the Worker Thread to finish loading the properties view configurations

In general, it seems very dangerous to synchronously jump to another thread during the activation of a bundle (Directly or indirectly). These calls to initializeDefaultPreferences() should be either:

- Done asynchronously (e.g. Display.asyncExec() or a Job) to avoid blocking Activator#start
- Done somewhere else (Not in Activator#start, but rather when these preferences are actually required)

Since these methods are generated, they affect all diagrams, but are especially visible for the Diagrams that contribute Properties View configurations, since Properties View Configurations are loaded in a background (non-UI) job