Re: [gui][patch] change to single-threaded event loop

[Michael Koch <konqueror at gmx dot de>]

Am Dienstag, 4. Januar 2005 20:34 schrieb graydon hoare:
> hi,
>
> this patch, which I just committed to the java-gui-branch, reduces
> the number of threads needed to support the AWT event loop from 2
> to 1. it does this by having the dispatch thread move back and
> forth between iterating the native event loop (on the native side
> of JNI) and iterating the AWT event loop, up in java. events are
> transferred in batches, so that the JNI traffic isn't too heavy.
>
> in addition, I added support for the precise shutdown condition of
> AWT applications. when all windows are destroyed, and both the
> native and java event queues are empty, the (single) event dispatch
> thread exits, allowing the program to terminate along with its main
> thread.
>
> I tried to hack support for this scheme into the X toolkit as well,
> but I'm not certain how successful I was -- it runs, but behaves
> oddly -- since much of the X toolkit seems broken at the moment.

After merging your patch to classpath I get a weird SEGV when running 
GUI apps:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 22434)]
0x418ea953 in get_state (env=0xbfffeecc, obj=0x40356ec8, 
table=0x8175978)
    at /home/mkoch/src/classpath/work/classpath/native/jni/classpath/native_state.c:229
229       obj_id = (*env)->GetIntField (env, obj, table->hash);
(gdb) bt
#0  0x418ea953 in get_state (env=0xbfffeecc, obj=0x40356ec8, 
table=0x8175978)
    at /home/mkoch/src/classpath/work/classpath/native/jni/classpath/native_state.c:229
#1  0x418de327 in connect_awt_hook_cb (widget=0x82a2728, 
peer=0x40356ec8)
    at /home/mkoch/src/classpath/work/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c:1138
#2  0x41ce2121 in g_cclosure_marshal_VOID__VOID () 
from /usr/lib/libgobject-2.0.so.0
#3  0x41ccdc20 in g_closure_invoke () 
from /usr/lib/libgobject-2.0.so.0
#4  0x41ce1aa8 in g_signal_emit_by_name () 
from /usr/lib/libgobject-2.0.so.0
#5  0x41ce0be7 in g_signal_emit_valist () 
from /usr/lib/libgobject-2.0.so.0
#6  0x41ce0ee4 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#7  0x41b1fbff in gtk_widget_realize () 
from /usr/lib/libgtk-x11-2.0.so.0
#8  0x41b2f3ef in gtk_window_reshow_with_initial_size () 
from /usr/lib/libgtk-x11-2.0.so.0
#9  0x41ce2121 in g_cclosure_marshal_VOID__VOID () 
from /usr/lib/libgobject-2.0.so.0
#10 0x41ccdfb7 in g_cclosure_new_swap () 
from /usr/lib/libgobject-2.0.so.0
#11 0x41ccdc20 in g_closure_invoke () 
from /usr/lib/libgobject-2.0.so.0
#12 0x41ce1451 in g_signal_emit_by_name () 
from /usr/lib/libgobject-2.0.so.0
#13 0x41ce0be7 in g_signal_emit_valist () 
from /usr/lib/libgobject-2.0.so.0
#14 0x41ce0ee4 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#15 0x41b1f3b6 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x418e5c62 in 
Java_gnu_java_awt_peer_gtk_GtkWindowPeer_nativeSetVisible 
(env=0x40356ec8, obj=0x40356ec8, visible=1 '\001')
    at /home/mkoch/src/classpath/work/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c:229
#17 0x0805c639 in callJNIMethod (env=0xbffff0ec, class=0x0, 
sig=0x806a868 "(Z)V", ret_type=2, ostack=0x808518c,
    f=0x418e5c00 "U\211å\203ì\030\017¶E\020\211]øèÞþþÿ\201â\231", 
args=2) at dll_md.c:64
#18 0x0804e154 in callJNIWrapper (class=0x0, mb=0x81b0234, 
ostack=0x40356ec8) at dll.c:301
#19 0x0805257e in executeJava () at interp.c:1986
#20 0x0804ebe2 in executeMethodVaList (ob=0x0, class=0x40356ec8, 
mb=0x8127520, jargs=0xbffff2b0 "4\006 @\001") at execute.c:66
#21 0x0804ea76 in executeMethodArgs (ob=0x40356ec8, class=0x40356ec8, 
mb=0x40356ec8) at execute.c:38
#22 0x08052fc2 in main (argc=2, argv=0xbffff324) at jam.c:303


Perhaps you know what the reason for this is. Merging Tom's additional 
patch doesnt help either.


Michael
-- 
Homepage: http://www.worldforge.org/