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