Re: [Java-gnome-developer] Keeping GUI responsive with java-gnome

[Andrew C. <an...@op...>]

Sorry I couldn't give you a longer response before, but I wanted to get
the one-liner out in the brief moment I had an available network
connection. If you're an experienced Java programmer and know about
workers then you'll get it fine, but for anyone who is new in this space
I wanted to write a longer explanation, follows:

On Mon, 2010-02-08 at 17:49 +0100, Björn Hurling wrote:
> I am having trouble keeping my GUI responsive while doing a lengthy 
> operation.

So, as is common in GTK land, we have to take care of not blocking the
main loop. Sounds like you're across that, as you say:

> At least that's the way how I could do it in C. 

:)

>  This is what I found on a code writing guide for Rhythmbox: 
> "Many times when some code has to perform a long computation or task, it 
> is actually a small task which is repeated many times."

Indeed.

So, the thing is this: in old world GTK programs written-in-C, the
technique was to use an "idle callback". This runs when the main loop is
"idle", which is not precisely true; it runs *blocking* the mainloop
after the current set of X events are processed. But it's all in the
same (single) process thread.

That was fine in single CPU, single core days, but anyone who has been
using multiple CPUs noticed that your typical GTK app (be it C or
especially Python) would be really really good at maxing out 1 CPU while
the other 3 sat there idle. That's single process single thread
computing for you.

Of course, the miracle of multiple cores per CPU means that just about
everyone has an SMP system these days.

[Which is why I'm a big fan of threads (if used carefully and properly
of course; programming is still programming and has to be done well)]

So the Rhythmbox code noting about small tasks is highlighting the
notion that you can, between small tasks, block your real work and let
GTK spin a bit, before blocking GTK and getting back to your real work.
Which beats the hell out of blocking GTK for a long time (and hence
losing responsiveness) but isn't making terribly good use of available
resources.


> Unfortunately these equivalents no longer 
> exist in version 4. Can anyone tell me why these methods were removed 

Well they never existed in java-gnome 4.0, so they weren't "removed".

++

We transparently do the work to use GTK's thread-safety mechanism
correctly.

Actually, GTK's thread awareness mechanism is just a big global lock,
which isn't ideal but that's the way it has to be to keep GDK and X in
sync, so that's the way it is. It's not an issue if all your work is
(say) network heavy and happily running in another thread. It is
discussed here:
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Gdk.html
and was originally implemented as described here and here:
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html
http://blogs.operationaldynamics.com/andrew/software/java-gnome/thread-safety-for-java.html
if you're interested in the background.

So, the answer to your question is "use a worker thread". This applies
both for quick one-off validations in Button handlers, but more
generally you have one (or maybe more) threads doing the heavy lifting
[I/O, whatever] while occasionally making GTK calls to update selected
minor elements of the GUI. Meanwhile the main thread can otherwise do
it's thing happily and you have a responsive app.

The important consideration remains not blocking the GDK lock, be it in
a [main thread] signal callback, or in a GTK call from some other
thread . If you do that, you'll block the main loop from iterating, and
you'll stall your user interface. So in that regard, it's no different
than C. GTK is GTK.

Indeed, all of this applies if using GTK multithreaded from C or C++.
It's just a lot easier to do in Java.

Hope that helps,

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London