Community
Participate
Working Groups
3.2M6 - create Untitled Text File - paste some text (or presumably any other change) -> the operation takes very long and the following stack appears in the thread dump This is while a CVS update is running. "main" prio=6 tid=0x00037b80 nid=0x370 in Object.wait() [0x0007e000..0x0007fc40] at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.Semaphore.acquire(Semaphore.java:38) - locked <0x1b11ab78> (a org.eclipse.core.internal.jobs.Semaphore) at org.eclipse.core.internal.jobs.OrderedLock.doAcquire(OrderedLock.java :169) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:1 05) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:8 2) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.j ava:97) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Worksp ace.java:1684) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1732 ) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOp eration.java:113) - locked <0x1b11abb0> (a org.eclipse.ui.actions.WorkspaceModifyDelegatin gOperation) at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(Wor kspaceOperationRunner.java:73) at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(Wor kspaceOperationRunner.java:63) at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation (TextFileDocumentProvider.java:459) at org.eclipse.ui.editors.text.TextFileDocumentProvider.validateState(Te xtFileDocumentProvider.java:1086) at org.eclipse.ui.texteditor.AbstractTextEditor.validateState(AbstractTe xtEditor.java:3685) at org.eclipse.ui.texteditor.AbstractTextEditor$19.run(AbstractTextEdito r.java:3736) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.ui.texteditor.AbstractTextEditor.validateEditorInputState (AbstractTextEditor.java:3731) at org.eclipse.ui.texteditor.TextEditorAction.validateEditorInputState(T extEditorAction.java:143) at org.eclipse.ui.texteditor.TextOperationAction.run(TextOperationAction .java:119) at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:185) at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyH andlerWrapper.java:109) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:460) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(Para meterizedCommand.java:424) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(Handle rService.java:160) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(Workben chKeyboard.java:466) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboar d.java:799) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(Workbe nchKeyboard.java:846) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindi ngs(WorkbenchKeyboard.java:564) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyb oard.java:506) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEv ent(WorkbenchKeyboard.java:122) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:982) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:924) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:949) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:934) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:962) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:958) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1272) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3346) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3246) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4023) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1879) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2964) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.jav a:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95 ) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformAct ivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runAppli cation(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ec lipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952)
We pass in 'null' as scheduling rule (just verified once again) for "untitled" files and hence acquiring the lock looks like a bug in Core. Moving there for comment.
Could you attach the stack trace for all threads?
Created attachment 38279 [details] Stack trace
The UI thread is not blocked due to a scheduling rule conflict. The thread Worker-156 in the attached stack trace is in the middle of a resource change event broadcast. We hold an internal lock to prevent concurrent changes to the workspace during resource change events. It appears that the CVS update is causing a lengthly recomputation of the project build paths from within the resource change event, and that's why the workspace runnable in the UI thread cannot proceed.
>We hold an internal lock to prevent concurrent changes to the >workspace during resource change events. Hasn't the scheduling rule story be invented to give the control to the client and hence he can tell whether to lock or not? It makes no sense to stop the main thread in this scenario, does it? Or is it to protect against clients which do not use scheduling rules?
Just to clarify my comment: I understand that the workspace is locked during the delta (probably to be backwards compatible) but what I do not understand is why my operation that specifies to not need locking is halted.
My explanation was a bit simplified. We don't hold that internal lock while a workspace running is executing. However, when Workspace.run is called we briefly acquire the lock before and after calling the runnable to do various bits of house-keeping - incrementing the operation counter, opening a new workspace tree layer to allow modifications, etc. This work is necessary because even though you haven't specified any scheduling rules, you are still requesting that your changes be batched into a single workspace change. In theory it may be possible to run this housekeeping code concurrently with the resource change event... However, it also seems that you don't need to call IWorkspace.run in the case where an untitled text file is being edited.
>However, it also seems that you don't need to call >IWorkspace.run We don't want to special case this. If we start doing so, we could probably change many code places in the SDK where scheduling rule 'null' is used and not call IWorkspace.run. Are you suggesting to do this?
workspace.run is a mechanism for batching resource changes, so if you have code where you never intend to modify any resources, then it doesn't make sense to call it. However, workspace.run with a null rule still makes sense in some cases. This means: "I intend to change resources, and I want the changes to be batched together, but I don't want to block other threads from changing the workspace concurrently". It may be possible to optimize the locking in the resources plugin to avoid locking at the start of the operation, but it's not something I'll be trying for 3.2.
Updating the title to accurately reflect the request. This is not currently possible because we need to create a new tree layer at the start of a workspace operation. The only solution I can think of is to avoid creating the new tree layer at that point, and to create it lazily when the first change is made. There is a bug report already for that, so I'll close this and marked it blocked on that bug.
