Warum nimmst Du die Windows MessageQue und nicht System.Messaging?
Dann kannst Du dir auch das ganze Pointer-Zeug sparen.

Warum nimmst Du eine TThread Klasse und nicht System.Threading?

Eine eigene Threadklasse nutze ich nur noch, wenn ich den Thread 1x Erzeuge und behalte...
Zum Beispiel um mit einen SetEvent(StartEvent) die Verarbeitung in Nano-Sekundenbereich beginnen zu lassen. Zum Beispiel,
wenn von der Eingangsqueue ein neuer SQL-Befehlt kommt.

Vorgehen:
- Ich gebe die SQL-Befehle in die ThreadSaveQueue. Bei Eingang wir der Event gefeuert und der Thread läuft sofort los.
- ich kann jederzeit neue Befehle in die Queue feuern und die werden nacheinander abgearbeitet.
- Der Thread erzeugt die Daten und packt diese in einen Ausgang-Queue. Damit ist der Thread frei für weitere Aufgaben.
- Da ich der Eingangsqueue eine anonyme Procedure mitgegeben habe, kann die Ausgangsqueue in einem 2. Thread nach und nach die Syncronize der anonymen Proceduren aufrufen, die die Daten in der UI darstellen.

Natürlich kann man das über die System.Threading auch machen! Ich nutze jedoch eine TThread-Klasse, da ich hierüber den MultiThread-Zugriff auf eine SQLite Datenbank serialisiere!

Wenn ich mit MultiThread/MultiConnectionfähigen Datenbanken arbeite, nutze ich natürlich den ThreadPool, um so viele Anfragen wie möglich gleichzeitig zu handeln und die Skalierbarkeit des Datenbankservers auszunutzen.

Mavarik