Zitat:
a) Speicher-Fragmentierung
b) Java nutzt ein eigenes Thread-Management, und setzt nicht auf Betriebssystemthreads auf
a) muß zwangsläufig bei jedem Speichermanager auftreten. Speicherfragmentierungen sind auch garnicht das große Problem ansich.
b) ändert nichts an der Tatsache, verschlimmbessert es sogar nur noch. Denn Threads sind auf Windows DIE Alternative wenn man asynchrone Sockets benutzen will. Und asynchrone Sockets benutzt man unter Windows zur
TCP/
IP Kommunikation deshalb weil diese mit den vorhandenen Sempahoren/Events (Signaling) zusammenarbeiten und diese wiederum nur mit Threads einen Sinn ergeben. Möchte man also sauber eine asynchrone und nicht-gepollte Socket Kommunikation haben, die das Gesamtsystem nur minimal belastet, so benötigt man unter Windows eben Threads. Verzichtet man darauf wie zb. in JAVA so kann man auch nicht mehr diese Art der Kommunikation des Betriebssystemes benutzen und zwangsläufig erhöht sich die Gesamtlast des Systems.
Das Einzigste was mir als Alternative einfallen würde ist das man innerhalb eines Threads mehrere Client-Sockets abarbeitet. Das ist dann aber keine Frage des
OS oder der Programmiersprache mehr sondern nur eine Frage der Bibliothek die man benutzt zur Kommunikation. Sprich
INDY oder was anders.
INDY benutzt halt soviel wie ich weiß für jeden Client einen eigenen Thread. Ich persönlich arbeite nur damit (in kommerziellen Projekten) und hatte damit noch nie Probleme mit der Serverlast. Allerdings ist eine handfeste Aussage in diesem Punkt sehr schwierig, egal mit welchen Tools/
OS man arbeitet. Eine wirklich sichere Aussage wirst du nur bekommen wenn du selber dein System unter Last real testest.
Gruß Hagen