Server mit vielen Socketverbindungen - Threads oder select()?
-
rüdiger schrieb:
hustbaer schrieb:
Ich weiss nicht was du mit "ein thread pool skaliert nicht" meinst
naja, du erstellst N Threads und sobald du mehr als N Verbindungen hast, hast du ein Problem
Nein, ich meinte du hast N Threads in einem Pool die alle bloss "haben fertig" Nachrichten von asynchronen IOs abarbeiten. Im Prinzip denke ich dasselbe wie du vorgeschlagen hast, bloss eben mit einem Thread Pool anstelle eines einzelnen Threads. Und das skaliert dann recht gut
Aber du hast wahrscheinlich Recht, für einen einfachen chat Server braucht man wohl nur einen Thread. Zumindest solange es nur einen "Raum" gibt macht ein 2. Thread kaum Sinn.
Bei mehreren Räumen hört sich das sogar vernünftig an. Aber das geht ja nur gut, wenn jeder Nutzer für jeden Raum, den er betritt eine Verbindung öffnen müsste.
Natürlich würde es auch mit Threading klappen. Aber dann lieber kein Shared-State Threading, sondern eher Message basiertes Threading (ala Erlang)
Nö, es müsste nicht jeder User für jeden Raum den er betritt eine eigene Verbindung aufmachen. Ich denke bloss so: bei mehreren Räumen muss nicht jede Nachricht von jedem User in der selben (einzigen) Queue landen, bzw. die Nachrichten aus einer Queue müssen auch nicht an alle User verteilt werden. Man hat mehrere Räume, deren Queues man z.B. mit unterschiedlichen Mutexes schützen kann. So können N Threads in N unterschiedlichen Räumen gleichzeitig Nachrichten reinhängen bzw. auslesen, und dadurch macht es u.U. dann Sinn mehrere Threads zu verwenden. Vorausgesetzt es sind mehrere Cores da die man beschäftigen möchte. Mit bloss einem Core ist es wieder ziemlich witzlos. Genauso mit bloss einem Raum -- dann kann man sich nämlich wenn man bloss einen Thread verwendet den ganzen Synchronisierungsoverhead sparen.
