locking foo ...

[Michael Stahl]

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...