Bemerkungen zum ORBit-ORB

Externe Ereignisquelle im ORBit

Für die Ereignisschleife im ORBIT ist src/IIOP/connection.c zuständig. Die Verbindungen werden in der giop_connection_list-gesammelt.

vermutlich muß wie in MICO das ganze Abstrahiert werden, so daß andere Ereignisquellen eingebunden werden können. (Callback-Funktionen)

Der orbit-mt-0.5.7 het eine sehr viel schönere glib-1.2-Integration, das IIOP-Verzeichnis ist wesentlich aufgeräumt, da die glib-Hauptschleife auch Arbeit übernimmt.

Die Ergeinisquelle wird g_io_channel_unix_new aus einem Unix-Dateidescriptor generiert und mit g_io_add_watch in den Dispatcher eingehängt.
Wird nun innerhalb der Ereignisroutine ein CORBA-Aufruf gemacht, wie z.B. der push als Push-Suppier in einen Eventchannel, so funktioniert das im Single-Threaded-Modus. Beim Multithreaded-Modus kommt zwar der Aufruf korrekt beim Empfänger an, der ORB-Dispacher verklemmt sich aber, wie die Analyse mit dem gdb-5.0 zeigt:

Das Programm wird gestartet. mit C-d wird beim blokieren das Programm unter brochen.
mit info threads läßt man sich the Threads anzeigen
mit thread id wählt man einen Thread
mit bt läßt man sich den Stack anzeigen

Der Hauptthread sieht wie folgt aus:

0  0x400e9b2e in __sigsuspend (set=0xbf7fe8d4) at ../sysdeps/unix/sysv/linux/sig
#1  0x401b90c0 in __pthread_wait_for_restart_signal (self=0xbf7ffe40) at pthread
#2  0x401b5c40 in pthread_cond_wait (cond=0x8059570, mutex=0x8059550) at restart
#3  0x400691a6 in g_async_queue_pop_intern_unlocked (queue=0x8059660, try=0, end
#4  0x400693a4 in g_async_queue_pop (queue=0x8059660) at orbit_thread_support.c:
#5  0x40067cde in ORBit_wait_for_request_id (monitor=0x8059818, request_ids=0xbf
#6  0x40079a27 in giop_connection_wait_for_reply_multiple (connection=0x8059818,
#7  0x40079aa5 in giop_connection_wait_for_reply (connection=0x8059818, request_
#8  0x804a4de in CosEventComm_PushConsumer_push (_obj=0x8059998, data=0xbf7ffb28
#9  0x8049e3a in leser (cbd=0x8059bd0, rot=0) at fifo2ev.c:227
#10 0x8049c68 in readeventhandler (source=0x8059c38, condition=G_IO_IN, data=0x8
#11 0x4009105c in g_io_unix_dispatch (source_data=0x8059c50, current_time=0xbf7f
#12 0x400927c6 in g_main_dispatch (dispatch_time=0xbf7ffc4c) at gmain.c:656
#13 0x40092de3 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#14 0x40092f8c in g_main_run (loop=0x80511d0) at gmain.c:935
#15 0x400799f3 in giop_main () at giop-connection.c:381
#16 0x400598c4 in CORBA_ORB_run (orb=0x8051268, ev=0xbf7ffd00) at server.c:59

Stackframe #2 ist das entscheidende.

Die Analyse und der Hinweis auf der ORBit-Mt-Seite ergab, daß der Hauptthread die Requests abarbeitet, und die über eine Asynchrone Warteschange an die Arbeiterthreads weitergibt.
In #2 wartet er nun als Arbeiter auf die erlösende Antwort, die nur aus dem Main-Loop kommen kann.

Die Lösung war das Aufsetzen eines Arbeiterthreads, der auch über eine eigne Warteschlange seine Ereignise erhält.

Das Beispiel ist die ORBit-Implementierung des fifo2ev des CORBA-MMIMS

Arbeitsgruppe Komponenten/CORBA Informatik- und Netzwerkverein Ravensburg e.V Rudolf Weber