Faire un thread par client, à la vue actuelle du coût d'un thread (en mémoire et temps CPU pour le changement de contexte) est une très mauvaise idée.
Actuellement la meilleure stratégie consiste à utiliser le pattern Reactor (avec epoll ou select), associé à pool de thread (2 thread par processeurs est un bon consensus) pour gérer les travaux à effectuer (lecture/ecriture entrée/sortie asynchrones, calculs complexes, lancement de scripts [php/python/java/rails etc] etc ).
[^] # Re: Suggestions
Posté par ecyrbe . En réponse au journal Gophrier 0.1. Évalué à 1.
Actuellement la meilleure stratégie consiste à utiliser le pattern Reactor (avec epoll ou select), associé à pool de thread (2 thread par processeurs est un bon consensus) pour gérer les travaux à effectuer (lecture/ecriture entrée/sortie asynchrones, calculs complexes, lancement de scripts [php/python/java/rails etc] etc ).