002
23.10.2007, 21:41 Uhr
ao
(Operator)
|
Polling und Threads sind (ähnlich wie Rot und Kalt) keine Gegensätze. Gegensätze wären Polling und Interrupt-Betrieb, oder Event-Betrieb, oder wie man das im jeweiligen Betriebssystem nennt. Der andere Gegensatz wäre Single-Loop (Prinzip der großen Schleife) und Multithreading.
Du meinst hier vermutlich einen Multithread-FTP-Server (der für jede Client-Connection einen Thread aufmacht) gegenüber einem Singlethread-Server, der alle Connections in einer Schleife bedient.
Ich würde sowas nie single-threaded bauen (*), weil man bei der Multithread-Variante eine ganz einfache 1:1-Zuordnung von Client, Connection-Objekt, Thread-Objekt, transferiertem File, lokalem Datenpuffer und so weiter hat. Das kann man wunderbar in eine Handvoll Klassen gießen und zur Laufzeit dynamisch managen, und ob der Server 5 oder 50 oder 500 Clients bedient, spielt softwaretechnisch überhaupt keine Rolle. Einmal sauber entworfen und ordentlich getestet - für alle Zeiten fertig.
(*) vorausgesetzt, es gibt ein Multithreading-System, das ich benutzen kann.
Ich glaube auch nicht, dass die Singlethread-Lösung performanter wäre. Mit einem einzigen eingeloggten Client hat auch die Multithread-Lösung nur einen Thread (abgesehen von der Hauptverwaltung, die irgendwo auf neu ankommende Clients wartet, aber die tut ja auch nichts), und der kann richtig Gas geben.
Kommt ein zweiter Client dazu, dann muss die MT-Lösung regelmäßig den Thread wechseln, das stimmt. Aber auch der Singlethread-Server muss sich für jeden Schleifendurchlauf erst irgendwo einen neuen Kontext (Connection, File usw.) abholen und am Ende wieder wegspeichern. Ist also nicht so, dass der nix zu verwalten hätte. Die Frage ist, wer das performanter hinkriegt, ein hoch optimiertes und von echten Könnern geschriebenes Betriebssystem oder deine Routinen (nix gegen dich).
ao
Dieser Post wurde am 23.10.2007 um 21:42 Uhr von ao editiert. |
