On Tue, May 11, 2004 at 09:43:16PM +0200, Jeremy Monnet wrote: > 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 > .... ????? > > Ca marche toujours comme ca ? (c'est vraiment une question, sachant que > je n'y connais vraiment rien en C)
Oui. Par exemple (sans C): for i in `seq 1 200`; do mkfifo "f$i"; done for i in `seq 1 200`; do ( cat "f$i" & ) ; done for i in `seq 1 200`; do ( echo fish > "f$i" & ); done (on cr�e 200 fifos, 200 chats qui attendent a manger, on les nourrit tous et ils s'en vont. Entre les lignes, on peut s'amuser � regarder tous les chats qui attendent avec impatience.) -> �a marche sur un pentium 100Mhz avec 40Mo de m�moire. Ne pas oublier qu'Apache tourne souvent sur Linux, et sert de tr�s gros sites, et qu'une fifo n'est pas fondamentalement diff�rente d'une socket. Par contre: > 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]. Si les clients tournent �galement sur la m�me machine (comme c'est le cas avec des fifos)... heu, faut voir ce qu'ils essaient de faire, mais y'a sans doute de meilleures fa�ons aussi. Bien entendu, faire un plat de spagetti avec 100 boulettes et 100 tubes peut potentiellement impressioner un prof... mais je n'y parierais pas ma note. Y. - Ein Mensch, ein cerveau, ein thread von pens�e. [1] Les probl�mes de concurrences sont _toujours_ sous-estim�s. Ils sont la raison pour laquelle il a fallu si longtemps � Microsoft pour rendre Windows stable, et pour laquelle Hurd n'est toujours pas disponible apr�s plus de 12 ans de retard. Il ne faut jamais cr�er de threads sans une vraie raison valable, qui n'existe presque jamais (c'est � mon avis le cas de Apache et de Galeon, pour ne citer que deux exemples classiques).
