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

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

Hi!

Andrew:
> What would happen if fired off a tiny little worker thread inside our
> run()? 
> 
> [...]
> So I'm wondering if it'd help here... Inside run() 
> 
> 1. fire off a worker thread, 
> 2. have that worker thread be what calls 
> 
> maybe in some combination with Thread's join()...?

I guess the new thread would block when attempting to enter the
synchronized block in the translation layer, as the lock is held by the
original thread in the signal handler. As that thread is waiting for the
new (in the join()) I guess that will cause a deadlock.


> There are about 57 manually written synchronized () blocks in our
> code.
> So catching them all will take a bit of work.

With some luck, a regular expression hacking and eclipse replace feature
will do the job for us... I could try.


> More pertinently, that would be a LOT of effort to essentially make
> *1*
> method work. I don't want to say "we don't have coverage of Dialog's
> run()" but...


Yeah, I agree with you... This might better be job for the future, there
are more interesting things to do. In the mean time, we could just warn
about this ugly feature of our run. Another approach is to add a second
run(), maybe called runWithoutBlock() to be called inside signal
handlers, but it does not fix the 3-level lock neither.

Anyway, it is currently not so bad, anybody can use the Response signal
if it needs multi-threading working with run()... Note I have been
writing this kind of apps for years and never found that problem until
this week.

Cheers
Vreixo