From: Godmar Back (gback@cs.utah.edu)
Date: Thu Dec 17 1998 - 18:50:05 EST
>
> On Thu, 17 Dec 1998, Godmar Back wrote:
> >The awt toolkit deadlocks for Les Schaffer on his P/90.
> >
> >The program for which that happens is FileViewer.java (appended)
> >and it's likely somewhere in the pack call.
> >
> >The two threads that deadlock are the main thread and the awt event queue
> >thread, as one would expect.
>
> Indeed - I recently fixed an "active" deadlock (actually a infinite loop) which
> came up with the threaded (blocking) AWT. In Java_java_awt_Toolkit_evtWakeup()
> (evt.c), move the whole ..
> if ( !X->wakeUp ) {
> ..
> }
> ..
>
> block up into Java_java_awt_Toolkit_evtInit() (doesn't matter where, it just
> has to be initialized before the first nextEvent() call happens).
I think I've seen that with FileViewer too:
In this "active deadlock", nothing would go anymore (i.e, the buttons
wouldn't turn red as you moved over them), but -vmdebug DETECTDEADLOCK
also wouldn't kick in. For me, it only happened with the interpreter,
but I couldn't reliably reproduce it.
For Les, btw, the real deadlock happens 1.0b3 when run with
-vmdebug JTHREADNOPREEMPT --- which is cool cause it's reproducible.
>
> Let me know if this helps. Works fine on my current snap (which I will try to
> convert into a full patch before christmas)
>
That would be great.
I don't really feel comfortable making risky changes to the awt.
If you have minor fixes, I think people would both tolerate and very
much encourage you to check them right away even if you're not 110% sure
about them yourself --- you'll get developer feedback earlier this way.
Of course, I know that this is not always possible --- say if you're
changes are interwoven with others. You have to decide on a case-by-case
basis.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:21 EDT