Re: gdk threads ...

[Michael Meeks <michael meeks suse com>]

On Tue, 2012-05-22 at 16:07 +0200, Stef Walter wrote:
> If you have more details/links on how VCL gets around this, I'd be
> interested. A bit of a morbid curiosity perhaps :P

	Sure; here is some of it:

http://cgit.freedesktop.org/libreoffice/core/tree/vcl/win/source/window/salframe.cxx#n1023

	Grok for ImplSendMessage I guess, lots of it is synchronous to the main
thread. Those messages are handled here:

http://cgit.freedesktop.org/libreoffice/core/tree/vcl/win/source/app/salinst.cxx#n732

	Some boring stuff there for sure, but only ~70 lines of it.

> Perhaps VCL isn't generic enough to run into this problem? Or is it
> solved by handing off all OS window creation in the main thread ?

	Window creation, and a reasonably bounded number of other bits, as
you'd see in that switch statement :-)

>  Or running multiple windows message loops, and passing off received
> data to a main loop in another thread ?

	Having a separate worker / "GUI thread" might be another way to defeat
the constraints of course, but that is (IIRC) our 'main' thread.

>  Or perhaps it's just by chance that the
> problem hasn't been encountered during regular usage patterns?

	Certainly possible, but it seems unlikely - we have enough threading
problems elsewhere to cause crashes without this ;-)

> Right, obviously not fundamentally impossible (given Turing completeness
> and all that) ... the issue is whether it's possible to do in a general
> purpose and correct way.

	Sure :-) either way, the idea of doing all rendering in it's own
thread/process, is not an impossibly unpleasant one (IIRC Chrome does
that without horrendous problems), and this 'X server' thing even does
it too I hear ;-)

	The problem is the work required to get to there, from here, and the
apparent lack of obvious advantages, (perhaps GL's generally lame
threading support, and global context might be it I guess).

	ATB,

		Michael.

-- 
michael meeks suse com  <><, Pseudo Engineer, itinerant idiot