> > C'est un programme client/server et ils ont choisi de forker le > > processus server pour chaque client connect�. donc 100 clients, 100 > > processus servers, et donc 100 pipes entre le "maitre" et les servers > > (et l� c'est mon avis partial), cette architecture est > preque certainement mauvaise: � moins de n'avoir une machine > avec 100 processeurs, l'inter�t d'avoir 100 threads est > extremement limit�. Un seul serveur qui select(2) sur toutes > les fifos (ou toutes les sockets) fera sans doute aussi bien > l'affaire, sans avoir � se casser la t�te avec des probl�mes > de concurrences inutiles[1].
Il me semble que tu oublis compl�tement un petit d�tail : il faut que si l'un des serveurs part en vrille, il ne bloque pas les autres. Avec le syst�me envisag� par les �tudients en question, tu as la garantie qu'au pire il y aura 1/100�me du CPU occup� � faire n'importe quoi si un client fait planter un serveur. Avec la technique qui consiste � n'utiliser qu'un seul serveur, tu dois te palucher toi m�me le partage des ressources entre les clients, et ca reviens au m�me (sauf qu'il faut refaire soit m�me ce qui a d�j� �t� fait et �prouv�). En fait, tu ne peut pas balayer sous le tapis les probl�mes d'acc�s concurrent aux ressources. C'�tait pendant longtemps le probl�me de mysql si j'ai bien compris : il n'avait qu'une file de requete : une requ�te prenait trois heures ? tant pis, pendant ce temps l� les autres n'avancaient pas... Au total, le temps CPU pour traiter toutes les requ�tes sera le m�me (et m�me, il sera moindre), mais ce n'est pas un comportement acceptable.
