C'est étrange comme remarque (je parle des développeurs de Proxy). Franchement, les threads Linux sont en gros des threads posix gérés par le noyau, donc je ne vois pas trop. Il y a bien un truc compliqué au sujet de la gestion des signaux, point sur lequel les threads linux ne respectent pas le standard posix.
La seule idée qui me vient concerne le modèle d'implantation des threads linux : c'est un modèle one-to-one, c'est à dire qu'un thread applicatif correspond à un thread noyau. Ca veut dire qu'avoir 1000 threads dans une application sous linux, ça risque de ramer à mort. Mais il faut être crétin pour avoir 1000 threads dans une application. Ceci étant, certaines implantations des threads sont basées sur des modèles très compliqués many-to-many (cf http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html(...)) qui correspondent en gros à avoir un double ordonnancement, à la fois au niveau utilisateur et au niveau noyau : en gros, un groupe de thread de l'application est représenté par un thread noyau. Ca permet de faire des applications de bourrin, genre 1000 threads, justement.
Le problème, c'est que beaucoup de développeurs pensent que threads => performances, et on arrive à des trucs débiles (toujours les 1000 threads).
[^] # Re: Que vallent les treads sous UNIX?
Posté par boubou . En réponse à la dépêche MPlayer a forké. Évalué à 10.
La seule idée qui me vient concerne le modèle d'implantation des threads linux : c'est un modèle one-to-one, c'est à dire qu'un thread applicatif correspond à un thread noyau. Ca veut dire qu'avoir 1000 threads dans une application sous linux, ça risque de ramer à mort. Mais il faut être crétin pour avoir 1000 threads dans une application. Ceci étant, certaines implantations des threads sont basées sur des modèles très compliqués many-to-many (cf http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html(...)) qui correspondent en gros à avoir un double ordonnancement, à la fois au niveau utilisateur et au niveau noyau : en gros, un groupe de thread de l'application est représenté par un thread noyau. Ca permet de faire des applications de bourrin, genre 1000 threads, justement.
Le problème, c'est que beaucoup de développeurs pensent que threads => performances, et on arrive à des trucs débiles (toujours les 1000 threads).