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 ...
