Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

[Vreixo F. <met...@ya...>]

Hi,

Andrew:
> Maybe that alone will help? Someone with a threaded program that
> demonstrates the bug will need to test that...
> 
> Attached is a bundle, so if you want to merge & try it, go ahead :)

I'm getting the same error as Guillaume. The problem is the stop
condition in the while. You need to use:


            while (!GtkMain.mainIterationDo(true)) {
                   ^  
                if (quit) {
                    break;
                }
            }

(And it will thrown the exception anyway if Gtk.mainQuit() is called, I
guess).

You also need a this.present() so the Dialog is actually shown.

Ok once I fixed this I tested it, but it doesn't work either. The reason
is the same as in the original problem. When native
gtk_main_iteration_do() is called, we hold a 2-level nested lock: the
one of the signal handler, plus the one in GtkMain.mainIterationDo(). 

I really think the easier approach is to replace the synchronize blocks
with another kind of Lock, as I have described in my previous mail.

Cheers
Vreixo

> 
> > Or maybe
> > 
> > 4. Write our own run()
> 
> 
> I had a preliminary try at it; see attached.
> 
> The idiom is pretty common; little inner class handler with a field so
> we can capture a value and return it.
> 
> By itself, this doesn't fix our lock problem. But I thought I'd show
> it
> to you in case it caused you to think of anywhere interesting to go
> from
> here.
> 
> Obviously the fact that we are iterating the real [outer] main loop
> rather than creating a(n implicit) new inner one is what is different
> compared to the real gtk_dialog_run().
> 
> Maybe that alone will help? Someone with a threaded program that
> demonstrates the bug will need to test that...
> 
> Attached is a bundle, so if you want to merge & try it, go ahead :)
> 
> AfC
> Sydney