Was passiert, wenn ein Event schnell hintereinander feuert?

[Jumpy]

Hallo DP,

wie ist das, wenn ein Event oft und schnell hintereinander feuert, sprich das Event feuert schon wieder, noch bevor das erste komplett abgearbeitet ist. Kann da was veloren gehen?

Wäre es sinnvoll, das Abarbeiten des Events einem Thread zu übergeben, so dass die Hauptanwendung den nächsten Event empfangen kann?

[Sir Rufo]

Von was für einem Event reden wir hier?

Ein Event, den die eigene Anwendung produziert, oder der durch eine Message ausgelöst wird?

[Jumpy]

Zitat von Sir Rufo:

Von was für einem Event reden wir hier?

Ein Event, den die eigene Anwendung produziert, oder der durch eine Message ausgelöst wird?

Ich glaube: Ein Event, den die eigene Anwendung produziert, aber als Reaktion auf etwas von aussen?

Ich habe eine IdhttpServer-Komponente in der Anwendung, die auf IdHTTPServer1CommandGet reagiert.

Die Anfrage selber kommt halt von einer Fremdsoftware über http, wobei mittels GET Request Parameter übergeben werden (und diese will ich analysieren und ggf. verwursten).

Und weil ich gerade diesen aktuellen Thread hier lese. Wenn ich das in Threads mache, könnten ja u.U. mehrere Threads gleichzeitig arbeiten, weil gerade mehrere Events schnell hintereinander kamen. Innerhalb der Threads würde ich gerne eine DB-Abfrage machen und auch ein Logging betreiben, entweder in eine Datei oder in eine separate DB-Tabelle. Das wäre aber auf jeden Fall etwas, wo sich die Threads Ressourcen teilen würden, und ich aufpassen muss, oder?
Am liebsten würde ich nämlich auch nur eine DB-Connection aufbauen, die dann (von den Threads) für alle Querys genutzt wird. Das wäre dann aber wahrsch. wieder ein Flaschenhals, so dass die Frage ist, ob dann Threads noch Sinn machen.

Hängt wohl an der Grundfrage: Können Events verloren gehen?

[Medium]

Events durch Messages ja, da die Messagequeue irgendwann so voll wird, dass nach gewissen Prioritäten verworfen wird.

Bei Callbacks, die Event-Mäßig implementiert sind nein, da sie synchron ablaufen, und den Aufrufer so lange blockieren, bis die Verarbeitung abgeschlossen ist. (Da könnte höchstens der Aufrufer so witzig werden, und den Aufruf in einem Thread machen, der mit einem Timeout- bzw. Loadhandling dafür sorgt, dass die Callbacks reduziert werden.)

Für deinen Fall klingt ein Worker-Threadpool sinnvoll (gabs auch ein nettes Framework hier in der DP zu meine ich), nur sollte auf jeden Fall jeder Thread seine eigene DB-Connection erhalten. Die DB selbst kommt dank ihrer internen Locking-Mechanismen prima klar mit gleichzeitigen Zugriffen aus mehreren Threads (dafür wuden DBMS u.a. schließlich gebaut ). Beim Logging in eine Datei, müsstest du selber sicherstellen, dass immer nur ein Thread da rein fummelt, was mit einer CriticalSection aber auch recht simpel ist.

Fazit: Wenn du unsicher bist, wie dein Aufrufer sich bei längerer Blockierung verhält, und/oder Fenster-Messages mitspielen, wäre eine threadbasierte Lösung keine schlechte Idee.

[schlecki]

Bekommt man bei den Indys nicht jede Anfrage in einem eigenen Thread? Zumindest bei den FTP-Komponenten ist das so.

[Jumpy]

Ich denke, ich werde das Thread basiert lösen und logging via DB, da ich mir dann um die Zugriffe keinen Kopf machen muss.

Welchen Sinn/Funktion hat dann der erwähnte Worker-Threadpool (hat die Wiederverwendung von Threads gegenüber der Neuerzeugung Vorteile?)?

Ich hätte jetzt naiv einen Thread erzeugt, der sein Ding macht und danach friedlich stirbt. Für jedes weitere Event ein neuer Thread.

P.S.: Geben Threads sich eigentlich selber wieder frei, wenn sie sterben?

[Klaus01]

Zitat von Jumpy:

P.S.: Geben Threads sich eigentlich selber wieder frei, wenn sie sterben?

.. wenn freeOnTerminate wahr ist, dann schon.

Grüße
Klaus

[taveuni]

Zitat von Jumpy:

Welchen Sinn/Funktion hat dann der erwähnte Worker-Threadpool (hat die Wiederverwendung von Threads gegenüber der Neuerzeugung Vorteile?)?

Ich hätte jetzt naiv einen Thread erzeugt, der sein Ding macht und danach friedlich stirbt. Für jedes weitere Event ein neuer Thread.

Zum Beispiel weil Du dann NULL Einfluss/Ahnung hast wie viele Threads erzeugt werden.
Wenn Du das mehrmals in Deiner Applikation machst und/oder dies auch Andere gleichzeitig tun
ist das Betriebssystem nur noch mit verwalten von Rechnerzeit beschäftigt.

Dies gibt dann so schöne Effekte dass sich der Rechner anfühlt wie ein 486-er.
Der Blick auf den Taskmanager gibt auf den ersten Blick auch nichts her.
Wenn dann aber im ProcessExplorer in einem Service > 1000 Threads sichtbar macht
sind die Fragen beseitigt.