Re: gdk threads ...

[Michael Meeks <michael meeks suse com>]

On Mon, 2012-03-05 at 13:16 -0500, Ryan Lortie wrote:
> To point at something concrete: attempting to use GTK on Windows from
> something other than the main thread will result in bad behaviour (even
> if you're holding the GDK lock) because Windows doesn't like you
> interacting with a window from a thread that is not the one that created
> it.

	Sure - this is why eg. VCL synchronously proxies the (rather few)
methods for which this is a problem to the thread that created the
resources, and creates such resources in that thread too. It takes, oh -
perhaps around a thousand lines of code to do that for VCL.

	My problem here is not with deprecation - I can understand that you
guys don't want to encourage people to use the code / assume that gtk+
is thread-safe: after all, you might forget to add a threads enter/leave
at some important place. HoweverLibreOffice's continued use of gtk+ is
predicated on this, modulo a very substantial re-write.

	It is easy for a toolkit author to make such a decision, it is harder
to re-write un-determined but large chunks of LibreOffice, and it's
extensions that casually use threads for their GUIs, etc.

	Thus far, we don't use gtk+ on windows, and have no immediate plans to,
so this is a unix-only problem for us, so I'd be up for deprecating the
GDK_THREADS_ENTER/LEAVE magic and hiding it except for just Unix.

	However without the ability to tell when the toolkit is itself calling
into itself from it's own idle handlers [ie. the enter/leave semantic]
it is not possible to safely extract / delegate locking to the calling
application / library / ecosystem.

	Given that gtk+ itself also uses other non-thread-safe pieces of
infrastructure, it will not be possible for other users to use pango,
fontconfig?, cairo? and other libraries that have any kind of
non-thread-safe global state / caching reliably. ie. this is a really
non-trivial change from our perspective.

	ATB,

		Michael.

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