C'est tout à fait normal !
C'est justement ce qui était repproché aux "linux threads".
Avant, les threads et les process passaient par une implémentation identique qui était la fonction clone() appellée avec différents paramètres (pour savoir ce qui sera partagé/recopié entre le process père et le fils).
Donc créer un thread revenait à créer un process un peu particulier.
Or désormais (et tel que POSIX le défini) les threads et les process ont chacun une implémentation propre et différente. Et tous les threads tournent dans un seul process (donc "ps" n'en affiche qu'un) ; c'est bcp mieux car conforme POSIX, et de plus l'implémentation des threads est bcp plus optimisée (car spécialisée) et donc bcp plus performante.
# Re: Kernel 2.6 / Gestion du multi-thread
Posté par Guinns . En réponse au journal Kernel 2.6 / Gestion du multi-thread. Évalué à 6.
C'est justement ce qui était repproché aux "linux threads".
Avant, les threads et les process passaient par une implémentation identique qui était la fonction clone() appellée avec différents paramètres (pour savoir ce qui sera partagé/recopié entre le process père et le fils).
Donc créer un thread revenait à créer un process un peu particulier.
Or désormais (et tel que POSIX le défini) les threads et les process ont chacun une implémentation propre et différente. Et tous les threads tournent dans un seul process (donc "ps" n'en affiche qu'un) ; c'est bcp mieux car conforme POSIX, et de plus l'implémentation des threads est bcp plus optimisée (car spécialisée) et donc bcp plus performante.
Vala