Community
Participate
Working Groups
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
PRODUCT VERSION: SH: JT 036, SDK 1.2.2
Can this defect be closed? From previous comments it appears that if you are careful, you can write long operations that are responsive. The outstanding issue is that the code that needs to be written is ugly/complex.
OK for me to close this one. FYI: I opened a new one regarding the modal behavior: parent of modal window not brought to front: http://bugs.eclipse.org/bugs/show_bug.cgi?id=7984
Closing