vcl::Window::dispose deadlock

[Michael Stahl]

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.