Ein Prozess ist nur ein Container für Threads. Da haben wir dem Mainthread und gegebenenfalls noch selbst erstellte weitere Threads. Wird der Prozess beendet, gibt Windows auch alle zugehörigen Ressourcen frei. Man "müllt" sich seinen Speicher also nicht voll. Windows ist wie die Mutter, die hinter einem aufräumt. Man kann jetzt also philosophieren, ob man es selbst tun sollte (Was "sauber" wäre.) oder es eben Windows überlässt.

Wenn ein Benutzer ein Prozess beendet, in dem er das Hauptfenster schließt, (Von "Abschießen" per Taskmanger wollen wir nicht reden, dann ist eh alles zu spät.) kann man diskutieren, ob man im OnClose des Hauptfensters noch allen Threads Bescheid sagt, sich beim nächst möglichen Zeitpunkt zu beenden oder ob man sagt: "Ach, egal. Windows macht das schon."

Hallo Dalai,

das sieht doch soweit ganz gut aus. Eine Sache die mir noch aufgefallen ist wäre folgende (das ist aber schon meckern auf ganz hohem Niveau):

Du durchläufst deine Execute Methode und feuerst zum Schluss das OnPingDone Event. Du rufst aber zuerst Synchronize auf und prüfst dann, ob das Event überhaupt abonniert wurde. Somit wartet der Thread zuerst, ob er sich mit dem Main Thread Synchronisieren kann. Und das kann Zeit kosten. Ich würde es umgekehrt machen. Das spart zwar nur ein paar Nano-/Milisekunden, aber wenn du dem Thread jetzt die Aufgaben geben würdest in einer Schleife mehrere Hosts abzufrühstücken, dann würde sich das u.U. bemerkbar machen.

Also könntest du aus deinem Code

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
    ReturnValue:= Integer(FClient.IsAlive);
  if NOT Terminated then
    Synchronize(CallOnPingDone);
end;

procedure TPingThread.CallOnPingDone;
begin
  if Assigned(FOnPingDone) then
    FOnPingDone(Self);
end;

folgenden Code machen:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPingThread.CallOnPingDone;
begin
  if Assigned(FOnPingDone) then
    FOnPingDone(Self);
end;

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
    ReturnValue:= Integer(FClient.IsAlive);
  if NOT Terminated then begin
    if Assigned(FOnPingDone) then begin
      Synchronize(CallOnPingDone);
    end;
  end;
end;

Oder gleich mit einer anonymen Methode das Synchronize aufrufen. Dann sparst du dir auch noch die Deklaration der CallOnPingDone Methode.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPingThread.Execute;
begin
  if Assigned(FClient) then
    ReturnValue:= Integer(FClient.IsAlive);
  if NOT Terminated then begin
    if Assigned(FOnPingDone) then begin
      Synchronize
      (
        procedure
        begin
          FOnPingDone(Self);
        end;
      );
    end;
  end;
end;

EDIT: Die Methode sind jetzt nur im Editor runtergetippt, sollten aber hoffentlich fehlerfrei sein. So viel habe ich jetzt ja auch nicht geändert.

Zitat von Luckie:

Windows ist wie die Mutter, die hinter einem aufräumt.

In einigen Threads bei StackOverflow wurde auch darüber diskutiert, und es kamen vergleichbare Antworten, in der Art: kurz vor dem Ende eines Prozesses noch aufzuräumen ist vergebene Lebensmüh. Ich ahnte schon, dass die von FastMM erkannten Lecks in Wirklichkeit keine sind, weil selbiger (FastMM) aus dem Prozess verschwindet, bevor die Ressourcen danach wirklich wieder vom OS zurückgeholt werden.

Was ich mich aber frage: Wie kann ich sicher sein, dass die Ressourcen tatsächlich wieder freigegeben werden? Gibt's vielleicht doch Ressourcen-Typen, bei denen das nicht ganz so einfach ist?

Zitat von Aviator:

das sieht doch soweit ganz gut aus.

Das freut mich .

Zitat:

Du durchläufst deine Execute Methode und feuerst zum Schluss das OnPingDone Event. Du rufst aber zuerst Synchronize auf und prüfst dann, ob das Event überhaupt abonniert wurde. Somit wartet der Thread zuerst, ob er sich mit dem Main Thread Synchronisieren kann. Und das kann Zeit kosten.

Verstehe. Nur am Rande: Ich hatte zuerst eine Prüfung auf Assigned in Execute stehen, dachte mir aber "Wozu in Execute und CallOnPingDone prüfen? Einmal reicht doch.", und nahm es aus Execute raus. Aber deine Erklärung ist plausibel und ich werde es wieder reinnehmen.

Danke an alle Beteiligten für die kompetenten Antworten!

Grüße
Dalai