Bug 68447

Created attachment 26820 [details]
Thread-dump

Imho  
org.openide.filesystems.FileObject.toString(FileObject.java:136) 
is too expensive and is responsible for the deadlock. 
 

/cvs/openide/fs/src/org/openide/filesystems/FileObject.java,v  <--  FileObject.java
new revision: 1.4; previous revision: 1.3

Another interpretation is that the "Refresh Loader Pool" thread is at fault for
locking the DataObjectPool. If all the refreshing were to run in the same thread
as "Folder recognizer" there would be no problem (I think). The patch may solve
this particular deadlock but it's far from clear to me that it would solve other
similar problems. If possible, I would recommend instead fixing
DataObjectPool.stateChanged to do its work in the folder recognizer thread. IIRC
the idea of the folder recognizer thread is that all major DS work should happen
there so that DS and Lookup do not deadlock one another (as is happening here).

For a while I thought Jesse is right. But I guess he is not.  
 
It is true that FolderList.changedDataSystem is called under a (package) 
private lock, but no foreign code is executed there: 
        FolderList list = find (folder, false); 
        if (err.isLoggable(err.INFORMATIONAL)) { 
            err.log ("changedDataSystem: " + folder); // NOI18N 
        } 
        if (list != null) { 
            list.refresh (); 
        } 
The only foreign code was the FileObject.toString() (and only due to logging) 
which Radek fixed. So I am affraid there is not much else that shall be fixed. 
Of course anyone is welcomed to write a test that will prove there is a 
deadlock...