Re: vcl::Window::dispose deadlock

On 09.06.2015 10:02, Noel Grandin wrote:
> On 2015-06-09 09:58 AM, Stephan Bergmann wrote:
> > On Windows, with master as of last night, "make check" happened to run into a deadlock in 
> > soffice.bin as below.  The
> > main thread is trying to re-acquire the SolarMutex (after a SolarMutexReleaser) from within the 
> > event loop, while an
> > incoming URP thread (apparently holding the SolarMutex) does vcl::Window::dispose which, on 
> > Windows, blocks on sending a
> > message into the event loop.

this started happening for me in sc_unoapi on a --enable-dbgutil build
almost always since half a year or so; before that it was less likely
for whatever reason but still did happen.  (the deadlock moved from
~Window to Window::dispose due to VclPtr refactoring.)

the deadlock does not appear easily fixable; the last slide of my
threading talk last year was about it actually.

this requires a larger re-design; either handling all VCL stuff only on
the main thread so that other threads never call Window methods, or
perhaps it would also work to have a dedicated thread that does nothing
other than handle the special thread affine Win32 create/destroy-window
messages and never takes a lock.

> Shouldn't something that blocks on sending a message into the event loop drop the SolarMutex 
> while it waits for the 
> reply, and then reacquire it afterwards?

no.  this is deep inside VCL internals which are very likely not in a
consistent state at this point, so other threads must be prevented from
calling into VCL.