Re: locking foo ...

On 11/12/13 16:33, Michael Meeks wrote:
> 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.

msdn says it's got room for 10000 messages ... and possibly more if you
edit a registry key :)

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

... but alas now i see it won't help much - when creating a window there
is the same problem with WinSalFrame::CreateFrame using SendMessage with
SAL_MSG_CREATEFRAME (to get the Win32 window created on the main
thread), and in that case it's of course hopeless to do anything
asynchronously.