Enfin pour etre precis, techniquement, on pourrait "fusionner" les NGPT et les NPTL (sachant que la premiere peut s'apparenter a une refonte complete des LinuxThread et la deuxieme a une tentative de nouveau standard posix thread) mais politiquement ca passe pas. (Y a eut pas mal de frittage/pressions au niveau de la libc pour l'integration d'une des solutions)
Maintenant il faut savoir que pour un kernel 2.4 utiliser les NGPT c'est vraiment pas terrible (car utilise pas mal de fonctionnalites des threads reelement utilisable dans le 2.5) alors qu'a l'oposee les NPTL n'utilisent pas les capacites du 2.5 a fond (d'ou le fait que des que l'on augmente le nombre de processeurs, ou qu'on joue avec bcp bcp de threads un gros ecart de perf apparait) bien que dans une utilisation minimaliste la NPTL est plus performante (car plus optimisee que NGPT)
Au final c juste une histoire de "politique", qd il se seront mis d'accord et que le 2.6 sortira je pense que l'on aura un bon hybride des deux (l'optim des NTPL et les nouveautes des NGPT), d'ici la...
Et pour info il n'y a pas incompatibilité binaire en linux-thread, NPTL, NGTL
heureusement a la base ces 3 libs sont toutes des implementations compatible posix thread.
Il faut que les programmes fassent une utilisation Posix des thread
Je me repete mais je croit que tu as tjs pas compris que du aux limitations actuelles de la norme posix thread, certains programmes critiques doivent avoir acces aux internes des implementations (si ca n'etait pas necessaire croit moi que les LinuxThread n'exporterait pas ses interfaces internes). Le seul cas un peu gore c'est valgrind qui doit, en plus d'emuler des calls kernels, emuler les internes des LinuxThreads pour les applis dans le cas sus-cite.
Le bon cote des choses c qu'avec les nouvelles fonctionnalites apportees par les NGPT il n'y aura theoriquement plus d'appli qui aurait besoin d'acceder au internes des implementations.
Si tout est posix, ça tourne indépendament avec linux-thread ou NPTL ou NGTL
Ca peut devenir faux! Si les NGPT deviennent comme le propose IBM la nouvelle norme posix thread (les NGPT sont juste une implementation pour montrer que ca marche, mais elle reste compatible avec l'ancienne qu'elle ne fait qu'etendre) ben un code nouveau Posix (a la NGPT) ne sera plus fonctionnel avec la NTPL
Les "gros" avec 8 cpus utiliseront NGTL les petit NPTL, etc...
Comme dis ci-dessus ca n'est pas aussi simpliste, le choix devrait, pour moi, tjs etre les NGPT mais a condition qu'ils integrent les optims des la NTPL.
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 2.
Maintenant il faut savoir que pour un kernel 2.4 utiliser les NGPT c'est vraiment pas terrible (car utilise pas mal de fonctionnalites des threads reelement utilisable dans le 2.5) alors qu'a l'oposee les NPTL n'utilisent pas les capacites du 2.5 a fond (d'ou le fait que des que l'on augmente le nombre de processeurs, ou qu'on joue avec bcp bcp de threads un gros ecart de perf apparait) bien que dans une utilisation minimaliste la NPTL est plus performante (car plus optimisee que NGPT)
Au final c juste une histoire de "politique", qd il se seront mis d'accord et que le 2.6 sortira je pense que l'on aura un bon hybride des deux (l'optim des NTPL et les nouveautes des NGPT), d'ici la...
Et pour info il n'y a pas incompatibilité binaire en linux-thread, NPTL, NGTL
heureusement a la base ces 3 libs sont toutes des implementations compatible posix thread.
Il faut que les programmes fassent une utilisation Posix des thread
Je me repete mais je croit que tu as tjs pas compris que du aux limitations actuelles de la norme posix thread, certains programmes critiques doivent avoir acces aux internes des implementations (si ca n'etait pas necessaire croit moi que les LinuxThread n'exporterait pas ses interfaces internes). Le seul cas un peu gore c'est valgrind qui doit, en plus d'emuler des calls kernels, emuler les internes des LinuxThreads pour les applis dans le cas sus-cite.
Le bon cote des choses c qu'avec les nouvelles fonctionnalites apportees par les NGPT il n'y aura theoriquement plus d'appli qui aurait besoin d'acceder au internes des implementations.
Si tout est posix, ça tourne indépendament avec linux-thread ou NPTL ou NGTL
Ca peut devenir faux! Si les NGPT deviennent comme le propose IBM la nouvelle norme posix thread (les NGPT sont juste une implementation pour montrer que ca marche, mais elle reste compatible avec l'ancienne qu'elle ne fait qu'etendre) ben un code nouveau Posix (a la NGPT) ne sera plus fonctionnel avec la NTPL
Les "gros" avec 8 cpus utiliseront NGTL les petit NPTL, etc...
Comme dis ci-dessus ca n'est pas aussi simpliste, le choix devrait, pour moi, tjs etre les NGPT mais a condition qu'ils integrent les optims des la NTPL.