On Wed, Jun 03, 2015 at 11:08:36PM +0200, Michael Stahl wrote: > On 03.06.2015 17:31, Lionel Elie Mamane wrote: >> On Wed, Jun 03, 2015 at 03:01:39PM +0200, Michael Stahl wrote: >>> On 03.06.2015 14:47, Lionel Elie Mamane wrote:
>>>> Since the problem is essentially that the two threads take the same mutexes >>>> in different order, here is a dirty hack that forces the hsqldb thread >>>> to take the "affine bridge" mutex before taking the "HSQL driver" >>>> mutex. >>> i'm not entirely sure this is sensible... >> Thinking the issue from yet another angle, if we go back to the >> situation at the start of this thread (hsqldb is *not* affine). I >> don't understand why the >> connectivity::hsqldb::ODriverDelegator::disposing thread holds the >> affine lock, and goes through the affine bridge: >> Why does the call from dbaccess::OConnection::disposing into >> connectivity::hsqldb::ODriverDelegator::disposing go through the >> affine bridge? > because OConnection is outside the affine environment, so it has to go > through the bridge to call a component inside the affine environment. > however the ODriverDelegator isn't inside the affine environment, what > happens is that while AffineBridge::v_callInto_v() waits for the call on > the "inner" thread to return, it assigns the current (calling) thread as > the "outer" thread and in AffineBridge::outerDispatch() it waits for > outgoing calls from the "inner" thread. You discuss what happens when the call goes into the affine bridge. I don't understand why it goes through the affine brige in the first place. -- Lionel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
