Der Thread wird aber doch nicht ständig Daten einlesen, sondern muss auch warten, *bis* Daten vorhanden sind. Dann ist eben nicht das Hauptprogramm zuständig, den Thread anzustoßen, sondern Windows bzw. die Indy-Komponente. Die hat doch mit Sicherheit ein Event 'OnData', oder?
Es gibt nur sehr wenige Außnahmen, wo ein Thread wirklich nonstop rechnen muss: Bei aufwändigen Berechnungen etwa, oder bei Echtzeitspielen.

I/O ist doch gerade dafür geschaffen, im Hintergrund 'en passant' abgewickelt zu werden, denn die meiste Zeit wartet man doch sowieso, bis endlich mal wieder ein Byte vorbeihuscht.

Man muss sich unter Windows davon verabschieden, in der klassischen Art und Weise I/O zu programmieren (nämlich durch polling). Statt dessen sagt man Windows, wen und was es aufrufen soll, *wenn* etwas passiert, also wenn z.B. Daten angekommen sind. Auch wenn man sich auf ein 'Read' setzt, passiert im Hintergrund nichts anderes.

Die ICS-Komponenten von Francois Piette (www.overbyte.be) sind komplett auf Events aufgebaut und damit asynchron und einfach als Komponenten zu verwenden. Der Nachteil an der Sache ist dann aber, das man Zustandsautomaten programmieren muss. Bei der SMPT-Komponente (emails lesen) muss man das Ereignis 'OnGetData'. Dieser Event wird immer ausgelöst, wenn etwas vom EMail-Server zurückkommt. Man programmiert also nur, wie sich die Anwendung verhalten soll. Damit kann dann das Versenden einer EMail wirklich parallel zum Hauptprogramm erfolgen, ohne auch nur einen einzigen Thread geschrieben zu haben.