Re: gdk threads ...

[Michael Meeks <michael meeks suse com>]

Hi Paul,

On Wed, 2012-04-25 at 09:05 -0400, Paul Davis wrote:
> there seems to be some confusion here. I've read back over your posts
> in the this thread. I don't see you mentioning libreoffice doing
> anything that requires thread enter/leave calls.

	Heh :-) sorry for the slow rate of response on this thread; no shortage
of tangled monsters to slay elsewhere just now.

>  You've mentioned idle callbacks, timeout callbacks. Idle callbacks
> can be setup without any thread locking (g_idle_add() and its cousins 
> are probably the one actually thread safe thing in glib/gtk :).

	I am intimately familiar with how the glib mainloop works :-) so yes,
I'm aware of this.

>  If you want separate threads with tie own main event loops (and, for
> example, their own timeouts) then you can do that, again with any
> thread enter/leave calls (ardour these days runs 3-4 glib event
> loops, for example). If you want other threads to be able to set
> up timeout callbacks in the GUI event loop, then just use
> g_idle_add() to get them set up.

	Please bear in mind that LibreOffice using glib/gtk+ exclusively as
it's toolkit / mainloop / cross-platform abstraction is not feasible in
the next many years even if the developer community were enthusiastic
about that; and even if it were a feature-complete replacement (which
I'd like it to be).

	LibreOffice is rather a complex piece of software. We integrate well
with eg. Java (of course, also concurrently Mono, python, StarBasic and
more) and we provide a (really naff) component / scripting binding for
our GUI to Java plugins, that API is thread-safe;

	Thus it is entirely possible to write a nice Java or StarBasic
component that sits there counting the number of words in a document,
itself generated from a live stream of data, and updating some widget
with the contents. It is fairly normal to see Java components using
threads [ as well as some vast vomit of worker thread / segv handler /
nightmare code arrive when you link the JVM ;-].

	While all that madness is going on, the application needs to continue
rendering, and pieces of code that we have no control of - such as the
gtk+ file-selector which does a ton of good asynchronous stuff, need to
continue to work [ie. not SEGV at random, we have enough of that ;-].

	So - yes, the solution of:

	* simply re-write -all- your code to make everything call
	  asynchronous / idle handlers on one-of-N glib mainloops

	Has the siren of simplicity for gtk+ maintainers to whom adding a
GDK_THREADS_ENTER / LEAVE pair in a few places seems to be a significant
burden :-)

	The only problem is, that re-writing the world, from scratch to adapt
to such a toolkit whim takes sufficiently long that by the time we are
done, people will have decided that in fact multi-threaded,
fully-concurrent toolkits are a cool idea, the new "one true way" to
expose wonderful interactive application parallelism ;-) & will have
switched back [ I speculate here of course ].

	So - deprecating this is fine by me, discouraging non-competent people
from using it makes lots of sense, but removing the functionality is
going to stop us being able to use gtk+, absent some -really-
substantial re-work impacting our code structure, component model, all
existing components etc. Without resources to do that, I'd really like
you to leave that stuff in - even if it is not perfect & may not be
complete - because I want us to be an application that is able to use
gtk+.

	Perhaps we can grab a whiteboard at GUADEC if anything is not fully
clear :-)

	Hope that helps,

		Michael.

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