On 04/12/13 00:02, Michael Stahl wrote: > On 03/12/13 22:33, Michael Meeks wrote: >> On Tue, 2013-12-03 at 17:03 +0100, Michael Stahl wrote: >>> and now for another fun problem i've seen: it's possible to deadlock >>> between the Win32 message handling in the main thread and deleting VCL >>> Window on other threads. the ~Window destroys the native Win32 window >>> by sending a Win32 message to it, and the Win32 window apparently is >>> tied to a thread such that that message send blocks until the main >>> thread gets the message and acts on it. >> >> >> Then again - that's a bit intractable; we have to destroy windows on >> the thread there were created on (unfortunately), and several other >> types of operation have to be done there - there is about a dozen of >> them in vcl/win. Each of these mandates a ~synchronous call to the >> 'main' thread succeeding during them. >> >>> so what can happen is that some other thread locks SolarMutex, deletes a >>> VCL Window, while main thread is in its message handling and tries to >>> lock SolarMutex itself, e.g. while getting a TopWindow via MSAA (but >>> there are many other messages which require locking SolarMutex); so this >>> is mostly a pre-existing problem and i'm not sure if anything can easily >>> be done about it; PostUserEvent apparently calls PostMessageW too so >>> likely has the same problem.
guess i should RTFM more - actually PostMessage is asynchronous, and SendMessage synchronous - so hopefully the deadlock can actually be avoided via PostMessage. what it does is call ~WinSalFrame which does things like remove "this" from a list of WinSalFrames stored in some SalData thing. if that could be moved to a SalFrame::Dispose() method to be called with SolarMutex locked, and the Win32 thread-affine stuff (DestroyWindow etc.) done from PostMessage we could be getting somewhere... _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
