• [^] # Re: MplayerXP fork de MPlayer avec support des threads

    Posté par . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 1.

    Ils sont juste plus facile à coder. L'exemple typique sont les serveurs multi-threadé qui enfle à chaque nouveau connecté. Si TUX (serveur web kernel plus rapide encore que khttpd) déchire tant c'est bien parce que il n'utilise pas un thread par connection ! On est bien d'accord qu'utiliser un thread par connection est une connerie, c'est un coup a se prendre un DoS a coup sur, mais c'est pour ca que le concept de thread pool existe. Mais si tu jettes un oeil sur la plupart des softs serveurs, les plus performants utilisent courramment plusieurs process ou plusieurs threads, ce qui revient plus ou moins au meme(qqe segments de memoire partagee par-ci par-la et c'est presque la meme chose). Ce n'est pas un hasard. SQL Server, Oracle, Zeus, Texis,... Tous ces softs utilisent plusieurs threads/process plutot qu'un seul thread, et ils n'ont pas ete ecrits par des manchots.