Ben desole mais je pense au contraire que l'approche threadee est bien plus judicieuse.
Ca permet de :
1) Faire le boulot tant que tu as le temps, tu ne sais pas si dans les 2 minutes qui suivent toto ne va pas lancer une compile avec un make -j 25 pour le fun ou autre truc bourrin qui va etrangler ton mplayer niveau acces CPU
2) Balancer la charge, plutot qu'avoir ton mplayer qui passe de 5 a 20% d'utilisation de temps en temps, la courbe d'utilisation CPU s'adoucit, ce qui est bien mieux point de vue temps de reponse
3) Le design est plus propre, et tire parti au mieux des perfs du systeme. Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 6.
Ca permet de :
1) Faire le boulot tant que tu as le temps, tu ne sais pas si dans les 2 minutes qui suivent toto ne va pas lancer une compile avec un make -j 25 pour le fun ou autre truc bourrin qui va etrangler ton mplayer niveau acces CPU
2) Balancer la charge, plutot qu'avoir ton mplayer qui passe de 5 a 20% d'utilisation de temps en temps, la courbe d'utilisation CPU s'adoucit, ce qui est bien mieux point de vue temps de reponse
3) Le design est plus propre, et tire parti au mieux des perfs du systeme. Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.