This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
A lot of deadlocks is caused by ProjectManager.MUTEX and its habit of doing filesystem operations and refiring them while the MUTEX is still in read or write state. This could be avoided if all ProjectManager operations first invoked masterfs.runAtomicAction( { MUTEX.xyzAccess( { ... } ) ). This is hard to enforce, as the MUTEX is part of public API and everyone can calls its methods. That is why I suggest an API that would allow the creator of a Mutex to wrap these calls by custom pre and post code executed outside of the mutex locks.
Created attachment 54156 [details] Proposed API with a test, however without implementation
This API should solve the deadlocks seen after last integration of issue 91291.
Created attachment 54167 [details] New API based on java.util.concurent.Executor
Created attachment 54168 [details] Sample usage of this API in projects to prevent most common deadlocks
I believe that this issue, together with issue 91291 can improve UI responsivness of project customizers. Please check the API and proposed impls.
Typo in apichanges: "priviledged"
Created attachment 54593 [details] Imporved patch that makes sure that only first entrace to the mutex invokes the Executor
Unless somebody objects, I'll integrate tomorrow.
http://openide.netbeans.org/source/browse/openide/util/test/unit/src/org/openide/util/MutexWrapTest.java?rev=1.2&content-type=text/vnd.viewcvs-markup http://openide.netbeans.org/source/browse/openide/util/src/org/openide/util/Mutex.java?r1=1.19&r2=1.20 http://openide.netbeans.org/source/browse/openide/util/nbproject/project.properties?r1=1.30&r2=1.31 http://openide.netbeans.org/source/browse/openide/util/apichanges.xml?r1=1.27&r2=1.28