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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice