[Java-gnome-developer] Worker thread blocks on GTK methods until after inner GTK main loop quits

[Thomas K. <tk...@gm...>]

Greetings list,

It seems the implicit synchronization done by java-gnome has
back-fired on me.  I'm having problems with worker threads blocking on
calls to GTK methods when they are started from dialogs that run in
inner GTK main loops.  Not until the dialog is closed (and its inner
GTK main loop quits) does the worker thread resume.

My best guess is that the GDK lock is held the entire the time dialog
is running by the currently-executing button listener that shows it.
The nested call to gtk_main is used to process the result of the
dialog 'in line' in the method that invoked it, rather than resorting
to callbacks, listeners/observers or some other continuation
technique.  As you know, gtk_dialog_run works exactly like this, and
exhibits the same problem (although the worker thread would have to be
started by some other thread in this case).

For example, pseudo-code for a button that greets the user after
asking for their name follows:
    In 'Greet' button Clicked event listener:
      - show name prompt dialog
      - wait until user closes it (using nested call to Gtk.main):
resume when the dialog calls Gtk.mainQuit as it closes
      - display greeting with the given name
Note that the GDK lock is held the entire time the dialog is running.
Any other thread (in my case a worker thread started by the dialog
itself) will block on any GTK call because the lock is not released
until after the dialog closes and the button handler returns.

The question is, how do I get around this?  Without the ability to set
GTK idle callbacks in java-gnome, I am forced to access GTK objects
directly from the worker threads themselves and accept java-gnome's
synchronization scheme, which is inadequate in this scenario.  The
button handler would have to return immediately after showing the
dialog in order to release the lock, that is to *show* the dialog
rather than *run* it in GTK-speak, and the dialog would have to invoke
a callback when it is closed to effectively 'resume' whatever the
button listener was doing.  I'd rather avoid this possible - things
would start to look too much like swing again...

Thanks in advance,
Thomas