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 ... -- .,p**"*=b_ Nicolas Rueff ?P" .__ `*b Montb�liard - France |P .d?'`&, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated.
pgpfgzIZJg3c3.pgp
Description: PGP signature
