Re: MplayerXP fork de MPlayer avec support des threads

Actuellement mplayer utilise deux proces (et non deux threads !) : - un pour la lecture - un pour le décodade et affichage Les deux proces sont utilisés uniquement si l'option -cache est spécifié. L'utilisation de deux proces est intéressante pour un fichier avi sur le réseau (http://....) car le noyau ne peut pas "bufferiser" ce qui est sur le réseau. En gros, il fait deja ce que je recommande :+) Avoir 2 threads ou 2 process n'est pas tres different, avoir 2 process rend les choses un peu plus compliquees car il faut gerer soi-meme les segments de memoire partagee mais a part ca il n'y a pas grande difference, un thread est moins lourd a creer qu'un process sur la plupart des architectures(normal, il y a moins de boulot a faire). Sans compter qu'avoir 2 threads plutot que 2 process, ca permet d'utiliser des spin-locks(bcp + rapide que des mutex dans bcp de cas car pas de context-swtich) sans se casser la tronche a gerer soi-meme leur creation dans des segments de memoire partagee. Bref, mieux vaut avoir des threads au bout du compte, ca simplifie.