Dans 99 % des cas, c'est /usr/include/pthread.h qui est utilisé.
linuxthread est une implémentation de la norme Posix 1003.1c : http://pauillac.inria.fr/~xleroy/linuxthreads/(...)
et jouer avec ce qui est spécifique à linuxthread ou nptl est rare.
> On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian,
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut : http://fr2.rpmfind.net/linux/redhat/9/en/os/i386/RELEASE-NOTES.html(...) This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Il n'y a que deux façon d'utiliser linuxthread avec RH9 ou > :
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
- utiliser la variable d'environnement LD_ASSUME_KERNEL
En pratique toutes les applis (à 99%) et depuis RH9 utilisent nptl. Depuis RH9, il n'y a qu'une appli que j'ai utilisé avec linuxthread : realplay (à lancer en fixant LD_ASSUME_KERNEL).
Le seul problème que je connais avec nptl est qu'il nécessite des instructions i686 pour marcher "nickel". Entre autre berkeley db est connu pour sucker sur arch < i686. Il n'y aura pas de correctif pour ce "bug" (c'est la conséquence du design de nptl).
J'ai vérifié, mysql sous RH9 (noyau 2.4.20 patché nptl), sans le moindre patch ou options à ./configure utilise nptl (la librairie, pas l'entête).
Pour "réellement" utiliser nptl, c'est-à-dire ne pas utiliser l'entête linuxthread et être le plus proche possible du standard posix, Le "standard" maintenant est d'utiliser "-pthread" avec gcc (compilation et link) et de ne pas "réfléchir" (sous FC3, /usr/include/nptl/pthread.h sera utilisé lors d'un "#include <pthread.h>").
Pour revenir plus ou moins à l'origine du thread, il me semble que gentoo n'a pas nptl par défaut (par défaut c'est aussi linux 2.4). Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native). S'il n'avait pas installé linuxthread les résultats seraient pires.
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 0.
Ici j'ai :
/usr/include/pthread.h (linuxthread)
/usr/include/nptl/pthread.h (nptl)
Dans 99 % des cas, c'est /usr/include/pthread.h qui est utilisé.
linuxthread est une implémentation de la norme Posix 1003.1c :
http://pauillac.inria.fr/~xleroy/linuxthreads/(...)
et jouer avec ce qui est spécifique à linuxthread ou nptl est rare.
> On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian,
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
http://fr2.rpmfind.net/linux/redhat/9/en/os/i386/RELEASE-NOTES.html(...)
This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Il n'y a que deux façon d'utiliser linuxthread avec RH9 ou > :
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
- utiliser la variable d'environnement LD_ASSUME_KERNEL
En pratique toutes les applis (à 99%) et depuis RH9 utilisent nptl. Depuis RH9, il n'y a qu'une appli que j'ai utilisé avec linuxthread : realplay (à lancer en fixant LD_ASSUME_KERNEL).
Le seul problème que je connais avec nptl est qu'il nécessite des instructions i686 pour marcher "nickel". Entre autre berkeley db est connu pour sucker sur arch < i686. Il n'y aura pas de correctif pour ce "bug" (c'est la conséquence du design de nptl).
J'ai vérifié, mysql sous RH9 (noyau 2.4.20 patché nptl), sans le moindre patch ou options à ./configure utilise nptl (la librairie, pas l'entête).
Pour "réellement" utiliser nptl, c'est-à-dire ne pas utiliser l'entête linuxthread et être le plus proche possible du standard posix, Le "standard" maintenant est d'utiliser "-pthread" avec gcc (compilation et link) et de ne pas "réfléchir" (sous FC3, /usr/include/nptl/pthread.h sera utilisé lors d'un "#include <pthread.h>").
Pour revenir plus ou moins à l'origine du thread, il me semble que gentoo n'a pas nptl par défaut (par défaut c'est aussi linux 2.4). Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native). S'il n'avait pas installé linuxthread les résultats seraient pires.