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

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

Hi,

> On Mon, 2010-08-09 at 21:42 +0200, Vreixo Formoso wrote:
> > I would like to discuss with you an ugly behavior related with the
> way
> > java-gnome automatically handles the Gtk thread-aware feature. I
> don't
> > really think this is a bug, but I would like to talk about it.
> 
> Yeah, I raised this on 13 Jan,

Ups, sorry! I didn't notice it.

> We could
> 
> 1. Take our own lock (which we could then manually unlock in special
> cases)
> 
> 2. Just mess with a manual MonitorExit/MonitorEnter
> 
> 3. Seriously mess with the entire main loop process:
> 
> [...]
> 
> All of these are invasive. #2 is probably easiest, but there's a
> bigger
> problem: what happens if you're not nested 2 deep, but nested 3 deep?
> Then it won't help.

ok, just a first sight opinion, I will review this in depth tomorrow:

First of all, I agree that 3) will be a pain in the ass. I don't think,
however, 2) would be a better solution: as you have noticed, you can be
nested 3 deep, or even 0 deep if you are not calling run() within a
signal handler (I wonder, however, if both cases could naturally arise
in a real application).

On the other hand, 1) could be a good solution and it seems not that
hard. We might just use java.util.concurrent.locks.ReentrantLock. I
think it is just a matter of changing the automatically generated
synchronized blocks in translation layer (plus any override that might
exist), and the C side bindings_java_threads_lock()/unlock() functions.
Then, we add an override for Dialog.run(), java-side, where, by means of
ReentrantLock.getHoldCount() and unlock() we release all locks but one,
then we call gtk_dialog_run(), and when it returns we finally acquire as
many locks as we originally hold.

I have not been working on this low-level stuff since some years, so
maybe I'm forgetting something... what do you think?

Anyway, I'm not really sure this bug deserves so much work at this
time...

Cheers,
Vreixo

> 
> > Note that in my opinion is it ok as it is now, you can always forget
> > about run() 
> 
> I don't have any hard opinions about it. It's a bug, and we need to
> either fix it if we can. I'd like to keep run(), though. It's nice to
> use inside signal handlers. Or it would be if it worked :)
> 
> AfC
> Sydney