java-gnome
public class Gdk
extends Object
Gdk... which give you access
to lower level drawing constructs; these are mapped in java-gnome as the
various classes within package org.gnome.gdk.
This particular class, on the other hand, simply contains some of the infrastructure necessary to permit multi-threaded access to GDK, GTK, and other GNOME libraries.
None of the other Java graphical toolkits out there let you make GUI calls from threads other than the "main" one; they're all single threaded. Even if all you want to do is a quick worker thread to carry out some input validation in the background after the user presses "OK", you have to jump through horrific contortions to do so safely, resulting in cumbersome, clunky code. By contrast, the java-gnome 4.0 bindings of GTK are transparently thread safe. We integrate properly with the underlying GDK thread lock and as a result you can safely make calls to various GTK methods from worker threads.
Threading and GNOME is tricky. This class mostly exists for the purpose of holding an object to serve as the global threading monitor and so that when the lock appears in thread dumps it has a useful name.
Every call made to the native libraries is protected by entering "the
master GDK lock"; those familiar with the C side of things would be used to
doing this via gdk_threads_enter() and
gdk_threads_leave(). When you initialize your java-gnome
program with Gtk.init(),
GDK is carefully configured so that the lock used is actually a Java side
monitor and therefore reentrant; nested calls all behave properly.
Note that when in a signal handler callback the GDK lock is already held
(you're "in" the main loop when a callback happens), but since it just
works transparently you don't need to worry about it. If you do find a need
to take the lock into account explicitly in your own code, the object is
available here, Gdk.lock.
| Modifier and Type | Class and Description |
|---|---|
static class |
Gdk.Lock
An inner class for the purely cosmetic purpose of giving an explicit
name to the global GDK lock.
|
public static final Gdk.Lock lock
synchronized monitors are reentrant you can proceed with
calling other java-gnome methods transparently, but keep in mind that
you are blocking the main loop during signal callbacks.
Most of the time you simply don't need to know about this; but should you have some reason to take the global GDK lock yourself, you can access it via this field.