Zitat:

Du lässt das Programm im Debugger laufen und während des VCL Hängers pausiert du den Debugger. Aus der Threadliste suchst du dir dann den VCL Thread heraus und guckst dir im Stacktrace an, in welcher Funktion er steckt. Je nachdem was er gerade macht, musst du das ein paar mal wiederholen.

Das habe ich versucht. In dem Moment wo ich auf Pause klicke in der IDE, minimiert sich die IDE. Meine Anwendung läuft bis dahin wieder (sind ja "nur" 7s der Hänger). Klicke ich auf die minimierte IDE in der Taskleiste, geht diese wieder auf und es steht nur eine Fehlermeldung da, dass der Debugger bereits gestoppt wurde. Pausiert wurde aber nicht und die Anwendung von mir läuft wieder ganz normal ohne Hänger.
Dazu eine Idee?

Also...

Hier gibt es ja schon viele Fragen und Antworten... Aber.

Zitat von AJ_Oldendorf:

zusammenfalten · markieren

Delphi-Quellcode:

while not Terminated do
begin

  //hier erfolgt eine Signalisierung über WaitForSingleObject und bei Timeout (=250ms), erfolgt der zyklische Aufruf unten
  if WaitForsingleObject(Irgendwas, 250, xxxx) = WAIT_OBJECT_0 do
  begin

  end;

  //zyklischer Aufruf
  TC := GetTickCount;

  //Synchronize(MeineFunktion);
  Queue(Nil, MeineFunktion);

  TC2 := GetTickCount - TC;
  //Protokollierung von TC2...
end;

Das ist natürlich der klassische Fehler für die Verwendung eines Threads (Übrings genau das behandle ich in meinem Talk in Amsterdam).

In einem Thread Queue aufzurufen ist natürlich nicht das Problem, aber nur um "Kleinigkeiten" auf der UI darzustellen. Die eigentliche Verarbeitung muss im Thread passieren.

WaitForsingleObject kann man nehmen, aber ich würde ein TEvent verwenden.

Da der Server ja immer nur eine Datenpacket nach dem anderen Empfängt würde ich die Aufgabe nicht an N-Thread pro N-Client weiter geben sondern das Datenpacket in eine Threadsichere Quere packen, die von X-Threads abgearbeitet werden.

Nur so ein paar gedanken.

Mavarik

Danke für die Tips.
Das WaitForsingleObject war ja ein Fehler, es wird ja so gemacht:

zusammenfalten · markieren

Delphi-Quellcode:

while not Terminated do
begin

  Return := MsgWaitForMultipleObjects (Handles, HandleBuffer, False, 251, QS_ALLINPUT);

  //case Return do
  //WAIT_OBJECT_0
  //WAIT_OBJECT_0+Handles
  // : begin
  // while PeekMessage(MessageData, 0, 0, 0, PM_REMOVE) do
  // begin
  // Mach irgendwas mit der Nachricht...
  // end;
  // end;
  //WAIT_TIMEOUT
  //end;

  //zyklischer Aufruf
  var sw := TStopwatch.StartNew;
  var TC : DWORD;
  var TC2 : DWORD;
  TC := GetTickCount;

  //Synchronize(MeineFunktion);
  //Queue(Nil, MeineFunktion);
  //ForceQueue(Nil, MeineFunktion);

  t1 := sw.ElapsedMilliseconds;
  //Protokollierung von t1 ...

  TC2 := GetTickCount - TC;
  //Protokollierung von TC2 ...
end ;

Das ist aber nur der Thread, der die Daten am Ende verarbeitet. Nicht der UDP Empfang oder Sender Thread...

Hat jemand mal ein Beispiel für Daten, die in eine Threadliste von einem Thread X geschrieben werden und von einem Thread y gelesen werden?
Ich möchte aber den Thread y auch per Message oder Event über bestimmte Dinge informieren können von außen.
Also ein Beispiel mit threadsichere Queue/Liste UND Event.

Dann kann ich das gerne mal versuchen, habe damit noch nichts zu tun gehabt

Ich kann es aus dem Code zwar nicht direkt ersehen, aber das MsgWaitXXX wartet vermutlich auf den/die Thread(s), die im weiteren Verlauf mit PostThreadMessage beliefert werden sollen. Das wird in der MS-Doku auch genauso beschrieben.

Aber trotz aller oft sicher auch berechtigter Kritik: Das Problem ist offenbar nicht in dem gezeigten Code zu finden. Das Kappen einer größeren Menge von Verbindungen und das daraus folgende Terminieren der Threads ist nicht die Ursache für das Hängen der VCL. Vielmehr löst es diese nur aus. Es geht also darum, die Ursache für den Hänger zu finden. Den Auslöser kennen wir nun ja schon.

Zitat:

Ich kann es aus dem Code zwar nicht direkt ersehen, aber das MsgWaitXXX wartet vermutlich auf den/die Thread(s), die im weiteren Verlauf mit PostThreadMessage beliefert werden sollen. Das wird in der MS-Doku auch genauso beschrieben.

Das wartet doch aber nur auf NEUE Messages für genau diesen Thread.
Warum sollte ein PostThreadMessage von jemand anderen (von außen) an genau diesen Thread, zu einem warten führen? Das ist mir nicht ganz klar.

Zitat:

Aber trotz aller oft sicher auch berechtigter Kritik: Das Problem ist offenbar nicht in dem gezeigten Code zu finden. Das Kappen einer größeren Menge von Verbindungen und das daraus folgende Terminieren der Threads ist nicht die Ursache für das Hängen der VCL. Vielmehr löst es diese nur aus. Es geht also darum, die Ursache für den Hänger zu finden. Den Auslöser kennen wir nun ja schon.

Danke Uwe, da stimme ich dir absolut zu. Die Frage ist immernoch, wie bekomme ich raus, was die VCL genau in dem Moment macht? Das pausieren des Debuggers geht ja leider nicht

Zitat von AJ_Oldendorf:

Warum sollte ein PostThreadMessage von jemand anderen (von außen) an genau diesen Thread, zu einem warten führen? Das ist mir nicht ganz klar.

Nicht zu einem Warten, aber zu einem Fehler (siehe https://learn.microsoft.com/en-us/wi...ssagea#remarks - das Bold ist von mir) :

Zitat:

The thread to which the message is posted must have created a message queue, or else the call to PostThreadMessage fails. Use the following method to handle this situation.

• Create an event object, then create the thread.
• Use the WaitForSingleObject function to wait for the event to be set to the signaled state before calling PostThreadMessage.
• In the thread to which the message will be posted, call PeekMessage as shown here to force the system to create the message queue.
  PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE)
• Set the event, to indicate that the thread is ready to receive posted messages.

The thread to which the message is posted retrieves the message by calling the GetMessage or PeekMessage function. The hwnd member of the returned MSG structure is NULL.

---

Zitat von AJ_Oldendorf:

Die Frage ist immernoch, wie bekomme ich raus, was die VCL genau in dem Moment macht? Das pausieren des Debuggers geht ja leider nicht

Das ist in der Tat nicht ganz so einfach. Das Hängen der VCL kann ziemlich viele Ursachen haben. Das kann z.B. auch das Schreiben einer Datei im MainThread sein, die vom Virenwächter oder dem Netzwerk ausgebremst wird. Du könntest ja mal zum Test das gesamte Logging ausblenden. Wenn es dann immer noch zu einem Hänger kommt, wird es daran vermutlich erstmal nicht liegen.

Zitat:

Nicht zu einem Warten, aber zu einem Fehler (siehe https://learn.microsoft.com/en-us/wi...ssagea#remarks - das Bold ist von mir) :

Ok, ich hatte dich falsch verstanden. Das PostThreadMessage erzeugt aber keinen Fehler, habe überall ein Else-Zweig und ein Breakpoint da drauf. Kommt nicht da rein.

Zitat:

Das ist in der Tat nicht ganz so einfach. Das Hängen der VCL kann ziemlich viele Ursachen haben. Das kann z.B. auch das Schreiben einer Datei im MainThread sein, die vom Virenwächter oder dem Netzwerk ausgebremst wird. Du könntest ja mal zum Test das gesamte Logging ausblenden. Wenn es dann immer noch zu einem Hänger kommt, wird es daran vermutlich erstmal nicht liegen.

Das werde ich mal versuchen.

Würde gerne nochmal darauf zurück kommen:

Zitat:

Hat jemand mal ein Beispiel für Daten, die in eine Threadliste von einem Thread X geschrieben werden und von einem Thread y gelesen werden?
Ich möchte aber den Thread y auch per Message oder Event über bestimmte Dinge informieren können von außen.
Also ein Beispiel mit threadsichere Queue/Liste UND Event.

Wenn jemand da etwas hat mit Daten über eine Liste und gleichzeitig Messagebehandlung/Event, dann würde ich das gerne mal versuchen

Zitat:

Das werde ich mal versuchen.

Logging deaktivieren:
Hat keinen Effekt auf die VCL. Hätte mich auch gewundert, da alles was mit Logging zu tun hat, an einen zentralen Log-Thread per PostThreadMessage geschickt wird und der liest entsprechend auch seine Queue aus und schreibt dann in die Datei.

Muss also noch was anderes sein...

Zitat von AJ_Oldendorf:

In dem Moment wo ich auf Pause klicke in der IDE, minimiert sich die IDE. Meine Anwendung läuft bis dahin wieder (sind ja "nur" 7s der Hänger). Klicke ich auf die minimierte IDE in der Taskleiste, geht diese wieder auf und es steht nur eine Fehlermeldung da, dass der Debugger bereits gestoppt wurde. Pausiert wurde aber nicht und die Anwendung von mir läuft wieder ganz normal ohne Hänger.
Dazu eine Idee?

Funktioniert das Debugging denn in anderen Projekten korrekt?

Zitat von AJ_Oldendorf:

Ich trenne die UDPClients gleichzeitig! und genau dann tritt das Problem auf.
Trenne ich nur EINEN Client, passiert das Problem NICHT.

Tritt das Problem nicht auf oder dauert es nur ein fünfundreißigstel so lang (und fällt deshalb nicht auf)?

Zeigt doch einfach mal den Quellcode, mit dem die UDPClients gleichzeitig getrennt werden. Hier scheint ja das Problem zu liegen. Eventuell macht der VCL-Thread in der Zeit ja garnichts, sondern wird von Windows erst wieder an die Arbeit gelassen, wenn alle UDPClients beendet sind?

Mögliche blockierende Freigabeoperationen(?):

Socket-Cleanup bei UDP-Clients erfolgt synchron im Hauptthread?

Massenhafte Freigabe (35 Clients) blockiert die Nachrichtenverarbeitung?