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' n.rueff@free.fr &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated.
Attachment:
pgpnDoiYR2k00.pgp
Description: PGP signature