On Wed, May 12, 2004 at 09:54:30AM +0200, Mickael Vera wrote: > Tu sera quand m�me oblig� de forker � chaque fois que ton > select trouvera une socket de disponible si tu ne veux pas > que le traitement d'une socket bloque les autres. Et le fork > est assez gourmand il me semble par rapport � des impl�mentations > l�g�res de threads.
"Si je ne veux pas": il faut donc faire le choix entre traiter N connections en s�rie � vitesse max V, ou bien traiter N connections en parral�le � vitesse V/N: avec la solution multi-process/multi-thread, on garanti qu'aucune connection ne peut �tre trait�e � vitesse maximale. Tout d�pend bien entendu de l'application et de la dur�e des connections, mais le multi-process est plus souvent inutile que le contraire. Le fork est l�g�rement plus gourmant que le thread, mais pas tellement plus sous Linux (essentiellement, il faut une structure de m�moire virtuelle par process alors que tous les threads d'un process partage la m�me, et il faut �galement changer le contexte quand on change de process... Une machine Linux change de contexte tout le temps de toute fa�on, l'impact de performance n'est pas en g�n�ral tr�s important). Y.
