Hi,
Also bei Nr. 1 handelt es sich um die Art der Implementierung, wie ich sie auch verwenden würde.
Die zweite Möglichkeit sieht zunächst verlockend aus, das man glaubt "vorarbeiten" zu können, hat jedoch m.E. mehrere gravierende Nachteile:
a) Starte Thread1 ... ThreadN. OK, und was passiert mit der N+1ten Anfrage?
b) Race condition: Dieses ist meiner Meinung nach das Hauptproblem: Dadurch, dass jeder Thread einen eigenen accept beinhaltet, kann es (ohne weitere Synchronisationsmaßnahmen wie z.B. Semaphore) zu folgender Situation kommen:
Thread1 beginnt accept (da er einen incoming request feststellt) und wird suspended BEVOR der Befehl vollendet wird.
Thread2 stellt ebenfalls einen incoming request fest, auch er beginnt mit der Ausführung des accept Kommandos (und wird auch fertig...). Er ist also "zuständig" für diesen request (und wird wieder suspended).
Nun darf Thread1 weiterlaufen - im besten Fall wird noch festgestellt, dass Thread2 schneller war, im mittleren Fall crasht der Thread1 mit Segfault und wenn es ganz blöd läuft, dann arbeiten beide Threads nun auf dem einen Request.
Grüße,
Richard