salut,
d'ailleurs cette impl�mentation des threads (noyau 2.4) n'est pas posix
alors que celle du 2.6 l'est.....
voil�, voil�
Manu
Nicolas Rueff a �crit :
Ainsi parla Nowicki Christophe le 348�me jour de l'an 2003:
Bonjour,
Une petite question existentielle que je me pose.
Pourquoi mon xmms fork t'il quatre fois?
$ps auxwww | grep xmms
cscm 596 0.1 1.3 17044 6960 ? SN 11:45 0:14 xmms
cscm 614 0.0 1.3 17044 6960 ? SN 11:45 0:00 xmms
cscm 615 0.0 1.3 17044 6960 ? SN 11:45 0:01 xmms
cscm 632 0.0 1.3 17044 6960 ? SN 11:45 0:00 xmms
Ce n'est pas un serveur web! Il n'a pas besoin de pre-forkier pour
tenir la charge. Alors pourquoi forkier et bouffer de la RAM en plus?
il ne bouffe pas de RAM en plus: c'est plus compliqu� que �a.
Bon, OK, je me lance: sous nunux, quand un soft fork, il duplique son
environnement: registres, piles, m�moire r�serv�e ... Donc en th�orie,
un process de 20Mo qui fork occupera 40 Mo en tout.
Dans la pratique, c'est pas �a du tout: nunux est _tr�s_ intelligent: il
ne duplique les pages m�moires que si elles sont modifi�es apr�s le
fork ou qu'il en a besoin. Un exemple:
soit un process P utilisant deux pages m�moire A et B.
- P fork: un fils F est cr�e (duplication des registres, blablabla);
- F a besoin de A au bout d'un certain temps: A est dupliqu�e;
- P modifie B sans que F en ait eu besoin: B est dupliqu�e (_avant_
modification, sinon c'est le souk).
conclusion: si on connait la taille m�moire du p�re, c'est par
contre difficile de connaitre celle du fils: �a d�pend des pages
m�moires qui ont �t� dupliqu�es. M�me top ne sait pas g�rer �a. mais �a
ira mieux avec les kernels 2.6 ...
Je n'est pas trouver l'option pour limiter le nombre de fork ...
normal, y en a pas.
Si quelqu'un a une explication?
Tr�s simple: quand tu fais un soft qui fait plusieurs choses � la fois,
vaut mieux les theader, et comme le fork est _tr�s_ efficace sous nunux
...
En plus, xmms utilise beaucoup de sockets pour communiquer av�
l'ext�rieur: d�mon audio (esd par exemple), ctrl � distance (socket
/tmp/xmms*), t�l�commande (lircd), ... et en techno socket, g�n�ralement
1 socket = 1 thread.
Je ne connais pas le fonctionnement de xmms, mais comme je le vois, il
est probable qu'il fonctionne comme �a:
- un thread "backoffice"
- un thread pour la GUI
- un thread pour la sortie audio / le d�codage
- un thread pour le contr�le � distance
pour info, mplayer utilise le m�me syst�me ...
