Re: [HS] linux et Pipes
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).
Reply to: