[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[Subclipse-users] Unsafe handling of resource deltas in TeamPrivateListener?

From: Niklas Deutschmann <niklas.deutschmann_at_methodpark.de>
Date: Fri, 9 Mar 2012 00:56:58 -0800 (PST)

Hi,

In my application, I'm occasionally observing the following behavior:

Display thread (main):
    // Do something in the workspace, in a runnable
    // that is run with fork=false (IRunnableContext.run() method)

Worker thread:
        WorkspaceMonitor$2.resourceChanged(IResourceChangeEvent) line: 215
        NotificationManager$1.run() line: 291
        SafeRunner.run(ISafeRunnable) line: 42
        NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 285
        NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 149
        Workspace.broadcastPostChange() line: 395
        Workspace.endOperation(ISchedulingRule, boolean, IProgressMonitor) line: 1530
        Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2353
        JobUtility$1.run(IProgressMonitor) line: 20
        Worker.run() line: 54

The resource change event that I get in WorkspaceMonitor$2 (my resource change listener) contains the changes I've done in *my* workspace runnable.

The runnable that is run in JobUtility$1 is the runnable that is scheduled as a job in TeamPrivateListener.resourceChanged(). This job is only setting the team private flag on directories, so the workspace changes should be clearly different from the workspace changes I've caused.

In TeamPrivateListener, the delta from the resource change is used later, in another thread, when the scheduled job is run. The Eclipse documentation states:

"If any of your update code runs asynchronously (i.e., you used asyncExec or some similar mechanism to post your code to another thread), there is another consideration to keep in mind. The resource delta objects supplied to your listener are designed to "expire" when the resourceChanged method returns. So, if you pass references to IResourceDelta objects to another thread, they may cause failures if they are accessed after the listener method has returned back in the other thread."
(http://www.eclipse.org/articles/Article-Resource-deltas/resource-deltas.html)

I don't observe the mentioned behavior when I handle the resource change event immediately (revert the change in r4682: http://subclipse.tigris.org/source/browse/subclipse?view=rev&revision=4682)

So, this seems unsafe to me.

In my application, I have to be prepared to get resource change events in any thread. But in my tests, I'm creating resources in the workspace and expect the results of my resource change listener to be visible immediately, so this behavior is causing test failures that can only be avoided by unloading the subclipse.core plugin.

Regards,
Niklas

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2933497

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2012-03-09 13:09:15 CET

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.