Bug 1898

Description Dani Megert 2001-10-10 22:21:49 EDT

When long running operations are executed the UI does not
	get enough cycles to refresh and then looks as if crashed to
	the user.

	Test Cases
	1. Start a full build (If it is too fast, do it running Eclipse in the debugger.
	2. Switch to another window (eg Netscape or Word)
	3. Switch back to Eclipse
		==> Only the text in the progress dialog is shown/updated
				all other Eclipse windows are not repainted


	OR: Use SlurpSplat: "Import Plugin Resources"


NOTES:

	KH (4/2/2001 8:43:56 PM)
		Need to check to see if these operations are run in a separate thread. 

	NE (04/04/01 3:50:47 PM)
		WorkspaceAction.run() uses run(false, true, op), which means don't fork.  Changed to true.
		BuildAction inherits this from WorkspaceAction.
		Where is code for SlurpSplat: "Import Plugin Resources"?

DM (4/17/01 3:43:44 PM)
	SlurpSplat plug-in is available via Self Hosting page:
		http://www.zrh.oti.com/webprojects/jabiru2000/documents/HowToSelfHost.html

	It also calls run(false, true, op)
	=> Fixed

	There are still 18 senders of run(false,*) in my workspace. JUI will revisit the code and change
	those that can be changed (i.e. not causing threading problems) to run(true,*). 

	Others should do the same.

NE (04/20/01 3:35:51 PM)
Other references which use false are as follows.
If any of these can take significant time, they should use true, otherwise the UI will be unresponsive.
If any of these access the workspace, or any other locks (e.g. JDI in the debugger), they should use true, 
otherwise there is the potential for deadlock, as follows:
	- concurrent thread T accesses workspace W 
	- at same time user initiates action in UI thread 
	- UI thread goes for W but it is blocked
	- T's access of W triggers notification, where some listeners do syncExec, but UI is blocked
	- ==> deadlock

com.ibm.eclipse.ui.editors.text.TextEditor.doSaveAs()
com.ibm.eclipse.internal.ui.Workbench.disconnectFromWorkspace()

com.ibm.eclipse.internal.help.workbench.search.SearchPage.ensureIndexIsUpdated(String, String)

com.ibm.eclipse.internal.ui.vcm.actions.VCMAction.run(IRunnableWithProgress, String)

com.ibm.dt.internal.ui.LaunchWizardDialog.nextPressed()

com.ibm.jdt.internal.ui.actions.AddGetterSetterAction.run()
com.ibm.jdt.internal.ui.javaeditor.AddImportOnSelectionAction.addImport(IJavaElement, ICompilationUnit)
com.ibm.jdt.internal.ui.actions.AddMethodStubAction.run()
com.ibm.jdt.internal.ui.actions.AddUnimplementedMethodsAction.run()
com.ibm.jdt.internal.ui.actions.AddUnimplementedMethodsAction.run()
com.ibm.jdt.internal.ui.reorg.CopyAction.processElements(Shell, Object, List)
com.ibm.jdt.internal.ui.packageview.FileTransferDragAdapter.runOperation(IRunnableWithProgress, boolean, boolean)
com.ibm.jdt.internal.ui.debug.JavaApplicationWizard.performFinish()
com.ibm.jdt.internal.ui.debug.JDIAttachLauncherWizard.performFinish()
com.ibm.jdt.internal.ui.wizards.NewElementWizardPage.invokeRunnable(IRunnableWithProgress)
com.ibm.jdt.internal.ui.javaeditor.OrganizeImportsAction.run()
com.ibm.jdt.internal.ui.refactoring.RefactoringWizard.performFinish(PerformChangeOperation)
com.ibm.jdt.internal.ui.refactoring.undo.UndoManagerAction.run()

NE (04/20/01 4:02:40 PM)
	Polled owners of occurrences above to annotate this PR.

NE (4/20/01 5:30:07 PM)
	EG replies:
		We have made a pass over our code this week and tried to address this issue, but it isn't
		easy. I've documented the issue in:
		1GCEE6Y: ITPUI:ALL - Architectural issue - using RunnableContext in "forked" mode