> Amúgy próbáltál már hibát megtalálni MT szerverben?
Hogyne. Az előző melóhelyemen egy több különféle szerver daemon-t írtam mind szervergépre, mind embeddedre és mind MT volt.
> Napokat el tud vinni, ahelyett, hogy fejlesztenél és valódi munkát végeznél.
Nem tapasztaltam. Egyáltalán nem emlékszem olyan esetre, amikor az MT szívatott volna meg valamivel, pedig a rohamtempós fejlesztések miatt voltak azért bugok. Szerintem csak megfelelő locking kérdése az egész, de nem nevezném magam expertnek a témában, úgyhogy ez csak az én véleményem.
> Eventes cuccokkal az a gond, hogy egy idő után egy istentelen bonyolult állapotgéped lesz, ami totál karbantarthatatlan kódhoz vezet. Sokkal egyszerűbb átlátni egy sima program flow-t.
> Egyszerű dolgokra viszont nagyon jók, ha rengeteg párhuzamos kapcsolatot kell kiszolgálni.
Az eventes megoldások eddig nekem kimaradtak; mindig
select()-tel szoktam dolgozni, mert a
poll()ahány rendszer, annyiféle szívás, míg a
select()mindenütt működik és mindenütt ugyanúgy működik. Viszont nagyon sok baja van, főleg a description set-ek kezelése egy agyrém. Ebből a szempontból a
poll()ezerszer jobb koncepció, de az összes rendszerben van valami hülye gyíkja és mindegyikben más. :(
> Pl. http alapú dolgot csak úgy érdemes csinálni szerintem, hogy egy event alapú szerver (pl. nginx) fogadja a kéréseket és továbbítja a multi process backendeknek. Ezeknek az összes perzisztenciája valamilyen event alapú szerverben (pl. memcached) vagy/és egy jól skálázódó adatbázisban van.
Ez a második fele már teljesen feladatspecifikus. Pl. statikus filekiszolgálásra minek kellene? Vagy akár sima infopage backendhez. A HTTP csak sima adatközlési protokoll, nem szükségszerűen webszerver.
> fork() (ill. multi process design) hatalmas előnye még, hogy izolálva vannak egymástól a processek címterei
Ez tény, viszont hatalmas hátránya, hogy a teljes process minden cuccát copyzni kell. Egy méretes processnél ez elég komoly overhead, a tanulmány is ezt feszegeti.