En gros c'est une facilite donnee aux gens, en leur disant bien que c'est dangereux et comment faire pour ne pas torcher le systeme
Je ne suis pas d'accord avec ce genre de politiques (de même que je ne suis pas d'accord avec Linus quand il refuse d'intégrer un patch qui interdirait de niquer physiquement le disque dur sous prétexte que root peut niquer ses disques durs s'il en a envie). Mais il y a quand même une grosse différence entre un /dev/kmem et une fonction d'API à laquelle il suffit d'attribuer une valeur pour planter le système. Peut-être que tu as un gros « NE PAS UTILISER » dans ta doc, mais les développeurs de Winamp n'ont pas du lire la même doc. C'est vrai que c'est plutôt le problème des développeurs de logiciels, mais il ne faut pas non plus les encourager...
Windows n'implemente pas mieux les normes POSIX vu que ce n'est pas un systeme qui se veut POSIX, mais il fait les choses correctement et proprement lui, ce qui n'est pas vraiment le cas du multithread sous Linux.
Sauf que l'exemple que tu prends (les PIDs des threads) a pour unique conséquence sous linux que les normes POSIX ne sont pas respectées.
Et inutile de decrire la peine que j'ai eu a trouver cette doc, sur la page de Linuxthreads il est dit que c'est maintenant partie de la libc, et dans la doc de la libc pas un seul mot sur les threads.
Chapitre 34 de la doc de la glibc, POSIX Threads. Je n'ai pas eu à chercher longtemps. Il y est écrit noir sur blanc qu'il ne faut pas mélanger threads et signaux. Ça tombe bien, les threads ça permet de se passer complètement des signaux.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
Un thread qui fait le timing et qui réveille les autres ?
Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Ce n'est pas tout à fait exact. J'ai essayé sous Solaris, on peut mélanger threads et signaux, et ça marche à peu près. C'est quand même tout aussi déconseillé.
T'as un soft qui cree un thread a chaque connection, le thread fait 2-3 choses et cree un process(avec fork) avec des droits reduits histoire de faire d'autres choses qui peuvent durer longtemps, apres le fork() le thread n'a plus d'utilite donc il est detruit, par contre tu veux savoir quand le process enfant est termine pour nettoyer 2-3 trucs.
Hé bin tu laisses le thread sur un waitpid(); c'est si compliqué que ça ? De toute façon, ça ne prend quasiment rien, comme ressources, vu qu'il y a déjà d'autres threads.
[^] # Re: linuuuuuuuuuuuuux
Posté par Jar Jar Binks . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 4.
Je ne suis pas d'accord avec ce genre de politiques (de même que je ne suis pas d'accord avec Linus quand il refuse d'intégrer un patch qui interdirait de niquer physiquement le disque dur sous prétexte que root peut niquer ses disques durs s'il en a envie). Mais il y a quand même une grosse différence entre un /dev/kmem et une fonction d'API à laquelle il suffit d'attribuer une valeur pour planter le système. Peut-être que tu as un gros « NE PAS UTILISER » dans ta doc, mais les développeurs de Winamp n'ont pas du lire la même doc. C'est vrai que c'est plutôt le problème des développeurs de logiciels, mais il ne faut pas non plus les encourager...
Windows n'implemente pas mieux les normes POSIX vu que ce n'est pas un systeme qui se veut POSIX, mais il fait les choses correctement et proprement lui, ce qui n'est pas vraiment le cas du multithread sous Linux.
Sauf que l'exemple que tu prends (les PIDs des threads) a pour unique conséquence sous linux que les normes POSIX ne sont pas respectées.
Et inutile de decrire la peine que j'ai eu a trouver cette doc, sur la page de Linuxthreads il est dit que c'est maintenant partie de la libc, et dans la doc de la libc pas un seul mot sur les threads.
Chapitre 34 de la doc de la glibc, POSIX Threads. Je n'ai pas eu à chercher longtemps. Il y est écrit noir sur blanc qu'il ne faut pas mélanger threads et signaux. Ça tombe bien, les threads ça permet de se passer complètement des signaux.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
Un thread qui fait le timing et qui réveille les autres ?
Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Ce n'est pas tout à fait exact. J'ai essayé sous Solaris, on peut mélanger threads et signaux, et ça marche à peu près. C'est quand même tout aussi déconseillé.
T'as un soft qui cree un thread a chaque connection, le thread fait 2-3 choses et cree un process(avec fork) avec des droits reduits histoire de faire d'autres choses qui peuvent durer longtemps, apres le fork() le thread n'a plus d'utilite donc il est detruit, par contre tu veux savoir quand le process enfant est termine pour nettoyer 2-3 trucs.
Hé bin tu laisses le thread sur un waitpid(); c'est si compliqué que ça ? De toute façon, ça ne prend quasiment rien, comme ressources, vu qu'il y a déjà d'autres threads.