Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 314121 - Lock-up on headless
Summary: Lock-up on headless
Status: RESOLVED FIXED
Alias: None
Product: Tigerstripe
Classification: Technology
Component: Headless (show other bugs)
Version: 0.5M1   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 major (vote)
Target Milestone: 0.5M0   Edit
Assignee: Richard Craddock CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-24 10:58 EDT by Eric Dillon CLA
Modified: 2010-05-28 05:38 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Dillon CLA 2010-05-24 10:58:29 EDT 
When starting Headless, there is a deadlock at startup between main thread and worker on the set up of Classpath Variables.

Ultimately this boils down to:

   <extension point="org.eclipse.jdt.core.classpathContainerInitializer">
      <classpathContainerInitializer
            class="org.eclipse.tigerstripe.workbench.internal.core.classpath.ReferencesInitializer"
            id="org.eclipse.tigerstripe.workbench.base.modelReferences"/>
   </extension>

triggering a worker to set up classpath variables, while the start() of the BasePlugin (activtor) eventually sets up classpath variables too. Leading to a deadlock as the start() being held up means that base plugin can't start (activator never finishes).
Comment 1 Eric Dillon CLA 2010-05-24 10:59:08 EDT 
Looks like an option is to have our classpath set up be done in a worker (thru a job) as well.
Comment 2 Richard Craddock CLA 2010-05-28 05:38:13 EDT 
Believe this has been fixed by provisiding the classPathVariables through an extension point rather than by calling them directly inthe start() method of the plugin