locking foo ...

[Michael Stahl]

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.