Zitat von DelTurbo:

Zum Thread. Der soll nicht schlafen, der soll arbeiten. Den gedanken gang kann ich leider nicht nachvollziehen. Ich habe das nun endlich so schnell, das ich mit bis zu 150MBit (im GBitLan) den MySqlServer "anblasen" kann.

Naja, ich hatte das so verstanden, dass dein Timer den Thread anstößt und der daraufhin Daten in einem globalen Objekt/Record zur Verfügung stellt und wiederum über ein globales Flag signalisiert, dass er fertig ist.

Nein, ich nehme mal die schuld auf mich damit keine weiteren diskusionen aufkommen. Das hauptprob ist ja, das ich schlecht die komplette source hier posten kann. Ich denke mal das würde den Thread sprengen, und nur mehr arbeit machen. Deswegen hatte ich versucht nur die hauptsächlichen sachen zu posten. Ich finde sowas relativ schwer, weil man was vergisst oder weglässt, weil ich selber es ja weiss.

Der Thread ist im grunde eine schleife die "vollgas" einen MySqlServer fillt (mit DirectMysql). Es war schon schwer genug, da einen guten speed zu bekommen. Deswegen der externe timer. Der (Apprun) wird in der schleife abgefragt. Hat er zugeschlagen gebe ich die infos aus. Damit man(n) nicht doof auf eine "Bitte warten" box schauen muss, sondern sieht wo er grade ist.

Allerdings muss ich sagen, seitdem ich Send statt Postmessage nutze, knallt es nichtmehr. Warum das so ist, weiss ich nicht. Zeitlich ist der unterschied nicht messbar.

Ich hatte in der abfrage extra noch "aufgepasst" das Postmessage wirklich zuende ist bevor ich sachen ändere und wieder ein Post schicke. Das habe ich extra gepostet. Daran hatte ich gedacht ^^

Also bei Threads halte ich mich immer an folgende Regeln:
1.) keine Windows-API Funktionen (z.B. BeginThread()) verwenden, sondern immer nur von der TThread-Klasse ableiten.
Der direkte Aufruf von Windows-API Funktionen ist hier viel zu gefährlich und fehlerträchtig.
Warum sich unnötigerweise in Gefahr begeben nur um einige Bytes und Microsekunden zu sparen?

2.) falls viele kleine Aufgaben zu erledigen sind, sollte man einen Threadpool in Betracht ziehen

3.) ein Thread sollte möglichst selbstständig und ohne Kontakt zu anderen Threads ablaufen.
Das bedeutet insbesondere: nicht auf globale Variablen zugreifen (ausser es geht nicht anderst).
Natürlich auch keine Funktionen aufrufen, die mit globalen Daten arbeiten.
Das Thread-Objekt bekommt alle nötigen Daten von Aussen über Properties übergeben und arbeitet dann mit seiner lokalen Kopie.
Die Ergebnisse des Threads werden über Properties zurückgegeben.
Man könnte die Thread-Klasse also unverändert ausschneiden und in ein anderes Programm einfügen, weil sämtliche Abhängigkeiten über Properties der Klasse bedient werden.
Das Prinzip ist EVA: Eingabe - Verarbeitung - Ausgabe

4.) Kommunikation mit der VCL vermeiden bzw. so gering wie möglich halten

5.) Innerhalb der Execute-Methode sollte man immer wieder das Property Terminated abfragen (Falls True, Thread sofort beenden)
Fragt man Terminated zu häufig ab, bremst das den Thread, fragt man zu selten oder gar nicht ab, behindert das das Verhalten (z.B. beim Herunterfahren von Windows).

6.) Exceptions innerhalb des Threads abfangen (andernfalls gehen sie verloren)

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMyThread.Execute;
begin
  try
    InternalExecute;
    ReturnValue := 0;
  except
    on E:Exception do
    begin
      OutputDebugString(PChar(E.Message));
      ReturnValue := -1;
      self.ExceptMessage := E.Message; // Meldung für später in einem Property merken
    end;
end;

Besonders Punkt 3. ist in der Praxis nicht so einfach und kann auch je nach Aufgabe nicht immer so erfolgen.
Aber die Probleme werden merklich reduziert.