Re: locking foo ...

Hi Michael,

On Wed, 2013-12-11 at 15:54 +0100, Michael Stahl wrote:
> guess i should RTFM more - actually PostMessage is asynchronous, and
> SendMessage synchronous - so hopefully the deadlock can actually be
> avoided via PostMessage.

        I suspect PostMessage is only async. up to a point - the queue is only
so large =) then again, if it discards after that I imagine we got our
point across.

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

        I guess we could queue up some main-thread tasks to do at least around
freeing resources when the main thread comes back something like an RCU
=) but that of course only handles frame destruction - there are a good
number of other bits that need a round-trip to the GUI thread that
created those handles.

        Whether those are involved in a11y is anyone's guess - but ... I for
one am a bit nervous of such a low-level change on the -4-2 branch. One
alternative might be to have a separate GUI thread that simply manages
those operations that cannot be performed on another thread =) that too
would involve some pain - writing a cut-down windows specific event-loop
that would execute it's own message queue - and (I assume) push window
events out of that into the main thread. That might give us a more
consistent model but at what performance cost ?

        HTH,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot