Sous RH et FC il y a nptl *ET* linuxthread.
Sous beaucoup d'autres distribs aussi. Sous ma gentoo j'ai mis les deux.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier)
Je l'ai compris il y a bien longtemps. ce que toi tu ne veux pas comprendre est que MySQL utilsie des inits de mutex en _NP qui justement font partis desdits cas particuliers
Je répète, mysql est codé ala linuxthread mais utilise nptl.
C'est faux. L'init de mutex de MySQL force LinuxThread en config standard (ie la config utilisé pour les tests)
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
Non. Le code d'initialisation des mutex, oblige l'utilisation des bibliothèques linuxthreads. La façon la plus simpel de savori si MySQL utilise LinuxThreads ou NPTL est de compter les process MySQL après lancement du démon. Si il y en a un c'est que les trois threads utilisent le même PID. C'est donc que NPTL a été utilisé, si il y en a trois c'est que LinuxThreads a été utilisé.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
Je ne parle pas des entêtes mais des bibliothèques systèmes. MySQL utilisant des fonctions non portables (ie non présente dans la norme Posix) doit être linké avec linuxthreads pour les versions citées plus haut. MySQL, dans son configure par défaut, a un besoin vital d'uen fonction non posix LinuxThreads qui n'existe pas dans NPTL (ni en réel, ni en interface mappée).
Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
Ca me parait très étonnant. Je veux bien croire que MySQL "Linke" NPTL pour une raison qui m'échappe, mais je ne pense pas qu'il s'en serve (du moins pas MySQL 4.0.22). Au niveau execution LinuxThreads et NPTL sont totalement incompatible et on ne peut donc pas les utiliser simultanément dans un même programme. A mon sens ilf aut compter les process. Si en compilant MySQL 4.0.22 avec un simple ./configure tu arrives à n'avoir qu'un seul process MySQL qui tourne c'est que tu as raison, ton MySQL utilise NPTL. Mais dans ce cas j'aimerais vraiment jeter un oeuil à ta config, parceque c'est théoriquement impossible.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Les threads sont créés avec la fonction 'clone' et ca s'arrête là. Tous les signaux systèmes passent quand même par le système natif et doivent être convertis. Le terme d'émulation n'est peut-être pas le bon, on devrait plutot parler d'enrobage (wrapping). Ceci étant les locks de mutex (par exemple, car ce n'est qu'un des quatre ou cinq points qui posent porblème, mais autant garder le même de bout en bout) doivent remonter jusqu'en userspace et redescendre à chaque fois...
soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
Plus lente non, plus problématique oui. Les threads dans FreeBSD sont assez pathétiques. Au final un MySQL compilé avec les options de base met à genoux un FreeBSD très facilement. Le threading sous FreeBSD est faiblard parfois, mais ça n'est pas la question.
Et alors ? C'est toi qui dit que le problême est autour des mutex.
Une fois de plus les mutexs ne sont qu'un exemple. C'est un des mainteneur des ports FreeBSD qui a évoqué que ca pourrait venir de là. Pour une liste de tous les problèmes liés à FreeBSD et la solution :
Je dis juste que le réalisateur du test aurait pu prendre des versions patchées de MySQL pour FreeBSD et que celà aurait rendu le test plus juste. Je ne prétend pas :
- Ni que FreeBSD est meilleur que Linux
- Ni que MySQL Tuné pour FreeBSD est meilleur que le MySQL tuné pour lInux
- Ni que le système de threading FreeBSD est meilleur que LinuxThreads.
Je dis juste que le test n'est pas juste en l'état.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 3.
Sous beaucoup d'autres distribs aussi. Sous ma gentoo j'ai mis les deux.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier)
Je l'ai compris il y a bien longtemps. ce que toi tu ne veux pas comprendre est que MySQL utilsie des inits de mutex en _NP qui justement font partis desdits cas particuliers
Je répète, mysql est codé ala linuxthread mais utilise nptl.
C'est faux. L'init de mutex de MySQL force LinuxThread en config standard (ie la config utilisé pour les tests)
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
Non. Le code d'initialisation des mutex, oblige l'utilisation des bibliothèques linuxthreads. La façon la plus simpel de savori si MySQL utilise LinuxThreads ou NPTL est de compter les process MySQL après lancement du démon. Si il y en a un c'est que les trois threads utilisent le même PID. C'est donc que NPTL a été utilisé, si il y en a trois c'est que LinuxThreads a été utilisé.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
Je ne parle pas des entêtes mais des bibliothèques systèmes. MySQL utilisant des fonctions non portables (ie non présente dans la norme Posix) doit être linké avec linuxthreads pour les versions citées plus haut. MySQL, dans son configure par défaut, a un besoin vital d'uen fonction non posix LinuxThreads qui n'existe pas dans NPTL (ni en réel, ni en interface mappée).
Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
Ca me parait très étonnant. Je veux bien croire que MySQL "Linke" NPTL pour une raison qui m'échappe, mais je ne pense pas qu'il s'en serve (du moins pas MySQL 4.0.22). Au niveau execution LinuxThreads et NPTL sont totalement incompatible et on ne peut donc pas les utiliser simultanément dans un même programme. A mon sens ilf aut compter les process. Si en compilant MySQL 4.0.22 avec un simple ./configure tu arrives à n'avoir qu'un seul process MySQL qui tourne c'est que tu as raison, ton MySQL utilise NPTL. Mais dans ce cas j'aimerais vraiment jeter un oeuil à ta config, parceque c'est théoriquement impossible.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Les threads sont créés avec la fonction 'clone' et ca s'arrête là. Tous les signaux systèmes passent quand même par le système natif et doivent être convertis. Le terme d'émulation n'est peut-être pas le bon, on devrait plutot parler d'enrobage (wrapping). Ceci étant les locks de mutex (par exemple, car ce n'est qu'un des quatre ou cinq points qui posent porblème, mais autant garder le même de bout en bout) doivent remonter jusqu'en userspace et redescendre à chaque fois...
soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
Plus lente non, plus problématique oui. Les threads dans FreeBSD sont assez pathétiques. Au final un MySQL compilé avec les options de base met à genoux un FreeBSD très facilement. Le threading sous FreeBSD est faiblard parfois, mais ça n'est pas la question.
Et alors ? C'est toi qui dit que le problême est autour des mutex.
Une fois de plus les mutexs ne sont qu'un exemple. C'est un des mainteneur des ports FreeBSD qui a évoqué que ca pourrait venir de là. Pour une liste de tous les problèmes liés à FreeBSD et la solution :
http://jeremy.zawodny.com/blog/archives/000203.html(...)
http://jeremy.zawodny.com/blog/archives/000264.html(...)
http://jeremy.zawodny.com/blog/archives/000697.html(...)
Je dis juste que le réalisateur du test aurait pu prendre des versions patchées de MySQL pour FreeBSD et que celà aurait rendu le test plus juste. Je ne prétend pas :
- Ni que FreeBSD est meilleur que Linux
- Ni que MySQL Tuné pour FreeBSD est meilleur que le MySQL tuné pour lInux
- Ni que le système de threading FreeBSD est meilleur que LinuxThreads.
Je dis juste que le test n'est pas juste en l'état.