Re: locking foo ...

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