To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=93051
------- Additional comments from [EMAIL PROTECTED] Thu Aug 28 10:54:22 +0000 2008 ------- So - a little more analysis; I imagine that the deadlock has always been there, but perhaps masked by the previous, more granular locking: you would have had to be writing the same piece of the tree that an activating component was wanting to read from previously to trigger it; now any write has the effect. IMHO the solution is not more granular locking to re-conceal the problem however. Perhaps I'm mis-understanding something, is it the case that the UnsafeBridge mutex is part of the new Kay Ramme threading framework ? if so, is it the case that almost whenever an UNO method is invoked on some code, that this lock is taken ? eg. if the configmgr wants to use the ServiceManager to instantiate a new service - then this code is deemed not-thread-safe, and thus the one-big-mutex is taken ? If so - we need to put configmgr inside that same appartment; since clearly it uses components outside it's scope and visibility to do (eg.) I/O - or even simple things like activating a service ;-) Of course, we can still leave the UnoApiLock construct against a time when the subsystems that configmgr relies on are thread-safe: the service manager, the explicit external services we use are: com.sun.star.io.DataOutputStream com.sun.star.xml.sax.Writer com.sun.star.script.Converter com.sun.star.comp.stoc.OServiceManagerWrapper none of which looks like it should be too horrific. Presumably things like the UCB and sax code are still viewed as thread-safe & not in the global apartment ? Ultimately - it's a simple lock ordering problem as Stefan points out. Code we call assumes that this UnsafeBridge mutex can be taken, but we have the UnoApiLock; while other code assumes that the UnsafeBridge mutex is already held and that we can then take the UnoApiLock. Ultimately IMHO, the best fix is to make these locks truly independent by killing all takes of the UnsafeBridge mutex in the (fairly basic surely) code that configmgr itself uses. Kay ? --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
