Bug 27804 - VariableContextManager and ExternalToolsPlugin#startup
Summary: VariableContextManager and ExternalToolsPlugin#startup
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Ant (show other bugs)
Version: 2.1   Edit
Hardware: PC All
: P2 normal (vote)
Target Milestone: 2.1 M4   Edit
Assignee: Darin Wright CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance, ui
Depends on:
Blocks:
 
Reported: 2002-12-05 17:30 EST by Darin Swanson CLA
Modified: 2002-12-12 12:17 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Swanson CLA 2002-12-05 17:30:44 EST
At startup the VariableContextManager is created and it starts listening to 
the "world" so that it can maintain a currently selected resource.

It appears that this is unnecessary...the VariableContextManager could resolve 
the selection when it is needed, that is in 
VariableContextManager#getVariableContext()
Comment 1 Darin Swanson CLA 2002-12-05 18:54:47 EST
Fixed in ExternalToolsPlugin and VariableContextManager.
Please verify.
Comment 2 Darin Wright CLA 2002-12-06 09:13:20 EST
The code is not always called from the UI thread, so this does not work.
Comment 3 Darin Wright CLA 2002-12-06 09:14:56 EST
For example, I have a tool that runs in the background (Notepad, as an external 
tool program). I select a file, and run notepad (using the argument 
${resoource_loc}), and I get an error dialog saying the variable could not be 
resolved.

I debugged it, and the ActiveWorkbenchWindow is null, so the code bails.
Comment 4 Darin Swanson CLA 2002-12-06 10:46:34 EST
Fixed in VariableContextManager.
I have added a syncExec (ack!).  Currently the code is always called from a 
modal context thread which means that the main ui thread is block so there 
should be no possibility of a deadlock (famous last words).
Comment 5 Darin Wright CLA 2002-12-06 12:12:31 EST
Hmmm. I have to think about this one for a bit - almost every sync exec we put 
in, we have taken out again due to deadlocks....
Comment 6 Darin Wright CLA 2002-12-09 16:55:39 EST
I think the problem is that someone can launch a config programatically, which 
could cause a deadlock (i.e. not from the the modal context thread). We should 
try this to see if it causes trouble.
Comment 7 Darin Wright CLA 2002-12-10 14:34:51 EST
As well, when a "resource refresh" occurrs after a tool is run (in a background 
thread), could this cause a problem? (if a variable is resolved to determine 
what to refresh).
Comment 8 Darin Swanson CLA 2002-12-10 17:09:52 EST
In the current code, the "resource refresh" is OK as the VariableContextManager 
is retrieved once and only once.

Others programmatic launching or retrieving the VariableContextManager might 
cause a deadlock

Note that I believe there was a bug in the old implementation as well...the 
Variable context manager was relying on the Plugin#startup method being called 
in the UI thread.

Comment 9 Darin Wright CLA 2002-12-10 17:35:21 EST
We may have to do the "async" trick for startup (like we do for image 
registry's?)
Comment 10 Darin Swanson CLA 2002-12-11 17:02:01 EST
Since we cannot guarantee no deadlocks due to the sync exec, I have rolled back 
and added the async in the startup of ExternalTools.
On build end I added nulling out the project.
Comment 11 Darin Swanson CLA 2002-12-11 17:02:36 EST
Please verify.
Comment 12 Darin Wright CLA 2002-12-12 12:17:57 EST
Verified.