Bien, je ne suis pas sur d'avoir vraiment bien compris la differences
entre les forks et les threads, le partage de memoire et les mutex ;)
Par contre les pipes (ou fifos) ne posent pas de probl�me, si ce n'est
une gestion plus complexe ? Donc ce n'est pas Linux qui pose probl�me,
mais plutot le code du copain qui a essay� ca avant de d�cr�ter que
finalement ca ne marchait pas correctement ?
Merci a tous pour vos r�ponses !
Jeremy
PS: je suis en train de lire un bouquin de prog sous unix, j'ai bon
espoir de comprendre tout ca d'ici a la fin de l'�t� !
Yves Rutschle wrote:
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.
--
------
Linux Registered User #317862
You want to use GNU/Linux or Windows ?
- You want to spend time or money ?
Why is Microsoft raising prices on you? Because they can !
- To take that power away from them, use Linux !
