DLL und Callback-Funktion: Hostprogramm reagiert nicht?

[romber]

Hallo!

Ich probiere es gerade mit DLLs, indem ich tesweise ein Add-On für mein Programm erstelle. In der DLL habe ich einen Thread mit dem TCP-Client, der sich mit dem Remote-Server verbindet und sehr viele Daten empfängt. Jeder Datensatz wird einer Callback-Funktion (im Hostprogramm) als Parameter übergeben. Diese Funktion wandelt dann die Daten in einem Objekt um und zeigt die Daten an. Wie gesagt, das Ganze nur zum Zwecke des Lernens.

Alles funktioniert ganz gut, solange die empfangenen Daten jeweils aus einem Datensatz bestehen und somit einzeln an die Callback-Funktion übergeben werden. Manchmal wenn der Datenaufkommen zu groß ist (oder warum auch immer) sendet der Server mehrere Datensätze auf einmal zu. In diesem Fall (um die Datenstau zu vermeiden) leitet der Client einen neuen Thread ab, der die Daten auffängt, aufteilt und einzeln der Callback-Funktion übergibt. Funktioniert auch. Das Problem tritt auf, wenn der Server mehrere "große" Datensätze hintereinander schickt und somit mehrere Threads hintereinander abgeleitet werden und sich gleichzeitig der Callback-Funktion bedienen. Dann friert das Hostprogramm plötzlich ein und reagiert nicht mehr. Es erscheint auch entsprechende Windows-Meldung, dass Programm nicht mehr reagiert.

Gibt es etwas, was ich beachten soll wenn ich
- Threads in der DLL erstelle
- die Callback-Funktion aus mehreren Threads in der DLL gleichzeitig aufrufe?

Sicherlich habe ich etwas nicht beachtet oder irgenwelche allgemeine Regel missachtet, die für soche Fälle üblich ist. Ich freue mich über jeden Hinweis.
Vielen Dank!

[BUG]

Zitat:

Zitat von romber (Beitrag 1216775)

- die Callback-Funktion aus mehreren Threads in der DLL gleichzeitig aufrufe?

Ist die Callback-Funktion thread-safe? Also: Gibt es keine Race Conditions oder Deadlocks?

[romber]

Zitat:

Zitat von BUG (Beitrag 1216778)

Ist die Callback-Funktion thread-safe? Also: Gibt es keine Race Conditions oder Deadlocks?

Ich denke schon. In der Callback-Funktion wird lediglich ein XML-Parser (himXML, danke an himitsu) erzeugt und mit übergebenen Daten gefühlt. Dann wird ein neues einfaches Objekt erstellt, dem die Values aus den XML-Nodes zugewiesen werden. Am Ende wird das neue Objekt einer Objektliste hizugefügt, natürlich geschützt mit TCriticalSection.

Aber auch wenn ich eine ganz einfache Callback-Funktion erstelle, in der ich die Daten einfach in einem TMemo anzeigen lasse, tritt der Fehler trotzdem auf.

[romber]

Das Problem ist immer noch da :|

[jaenicke]

Zitat:

Zitat von romber (Beitrag 1216782)

Aber auch wenn ich eine ganz einfache Callback-Funktion erstelle, in der ich die Daten einfach in einem TMemo anzeigen lasse, tritt der Fehler trotzdem auf.

Mit Synchronize natürlich?

Hast du Fehler in deinen Threads denn auch schön ordentlich mit einem try..except außen herum abgefangen? Denn Exceptions in Threads, die nicht abgefangen werden, können sich genau so äußern. (Anderswo auch, aber in Threads ist das besonders schlecht.)

Und dann gibt es da auch noch Tools wie MadExcept oder Eurekalog, die solche Exceptions abfangen und dir mitteilen wo das Problem aufgetreten ist.

[romber]

Zitat:

Zitat von jaenicke (Beitrag 1216825)

Mit Synchronize natürlich?

Nein. Wenn ich in der DLL den Aufruf der CallBack-Funktion in eine neue Thread-Prozedur auslagere und diese mit Synchronize aufrufe, passiert nichts. Ich meine, die Prouedur wird gar nicht aufgerufen.

[jaenicke]

Ah. Du versuchst das Synchronize in der DLL. Das geht so nicht, denn da fehlt der Aufruf von CheckSynchronize. Das musst du z.B. über eine exportierte Funktion der DLL aus deinem Hauptprogramm heraus in ApplicationEvents.OnIdle aufrufen.

Da das bisher nicht aufgerufen wird, wird dein Synchronize nie abgearbeitet...

[romber]

Zitat:

Zitat von jaenicke (Beitrag 1216835)

Ah. Du versuchst das Synchronize in der DLL. Das geht so nicht, denn da fehlt der Aufruf von CheckSynchronize. Das musst du z.B. über eine exportierte Funktion der DLL aus deinem Hauptprogramm heraus in ApplicationEvents.OnIdle aufrufen.

Da das bisher nicht aufgerufen wird, wird dein Synchronize nie abgearbeitet...

Ok. bevor ich jetzt wieder etwas falsch mache: ich erstelle jetzt eine neue Funktion in der DLL mit der Zeile

Delphi-Quellcode:

CheckSynchronize

, exportiere diese und rufe in der Hostaufendung einmal auf. Dann kann ich aus der DLL heraus mit dem hostprogramm synchronisiert. Richtig?

[romber]

Habe ich jetzt gemacht wie oben beschrieben. Hat sich nichts geändert. Die mit Synchronize augerufene Prozedur wird nicht ausgeführt.

[Der schöne Günther]

Nochmal von vorne...

1. Client "Hauptprogramm" bindet DLL ein
2. Hauptprogramm erzählt der DLL, welche Funktion es später einmal aufrufen soll, wenn es Datenmengen abzugeben hat
3. Die DLL tut viele Dinge, darunter auch mehrere Threads öffnen
4. Mehrere der Threads aus der DLL entscheiden sich nun innerhalb einer kurzen Zeitspanne, die Datenablieferungsfunktion aufzurufen
5. Die Funktion soll erst einmal nichts anderes tun, als die Daten, die sie übergeben bekommt, als Text in eine Memo zu werfen

Alles richtig bis hier?

Wenn ich zumindest das Problem verstehe, dann ist es die Tatsache, dass (der Thread aus) der DLL mit der ganzen VCL-Geschichte des Hauptprogramms nichts am Hut hat. Und somit beispielsweise auch erst garnichts im Kontext des Hauptthreads ausführen kann. Richtig?

Ich würde die Datenablieferungsfunktion so bauen, dass hier Daten einfach nur abgelegt werden. Beispielsweise in einer verketteten Liste (natürlich entsprechend geschützt, z.B. mit einem kritischen Abschnitt). In deinem Hauptprogramm würde ich z.B. jede halbe Sekunde hingehen und schauen, ob mittlerweile neue Daten vorliegen. Wenn ja, kann man die ja anzeigen.