vcl::Window::dispose deadlock

[Michael Meeks]

Hi Michael,

On Tue, 2015-06-09 at 11:36 +0200, Michael Stahl wrote:
> this requires a larger re-design; either handling all VCL stuff only on
> the main thread so that other threads never call Window methods

	Yep - this is the direction for travel for external toolkits I guess
and we could even put the problematic UNO toolkit/ API inside a thread
affine apartment (or something) to solve the historic scripting API
problems we have.

>  or perhaps it would also work to have a dedicated thread that does nothing
> other than handle the special thread affine Win32 create/destroy-window
> messages and never takes a lock.

	This approach OTOH is really rather easy ;-) I imagine having a
SalComWndProc custom thread would simplify a number of code-paths
really. I guess the concern there would be performance, but then - hard
to know what that is until we benchmark it - Windows appears to have a
very large number of similar "GDI worker" type threads itself lying
around in each application these days; we even have threads for
high-frequency timers which improves performance ;-)

	ATB,

		Michael.

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