- pour des raisons precisees dans la doc(les threads de managment n'ont plus le temps de tourner si un thread de plus haute priorite monopolise le CPU trop longtemps)
- infaisable par quiconque d'autre que l'administrateur
Tout comme ecrire dans /dev/kmem peut faire torcher ta machine.
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, et son utilisation est interdite a quiconque d'autre que l'admin pour eviter les abus, maintenant si tu trouves que ce genre de choses est un bug, ben faudra penser a corriger pas mal de choses se trouvant dans /dev et dans /proc.
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.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
4 threads qui tournent.
1 thread se reveille toutes les 30 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 40 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 30 secondes, les 40 secondes et les 2 minutes 15.
1 thread se reveille toutes les 30 secondes et les 40 secondes.
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.
Voila, tu peux aller t'amuser a modifier le handler de SIGALRM et faire un code degueu pour ca vu que les signaux sont partages par tous les threads, ou bien creer un thread qui passe son temps a recevoir les signaux et les dispatcher aux autres threads, pendant ce temps moi je cree sous Windows 3 objets timer , je leur assigne les temps, je fais WaitForMultipleObjects() dans chaque thread et c'est fini, c'est moins couteux en ressources car chaque thread n'est reveille que quand c'est necessaire et c'est plus propre a programmer. Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Si tu veux on peut aussi parler du probleme suivant:
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.
Ben avec Linux tu peux t'amuser, le PID parent du process enfant c'est le PID du thread qui a ete detruit, resultat il est impossible de le faire savoir au process grace au signal SIGCHLD et il faut faire des magouilles degueulasses genre stocker les PID des child process et faire du polling pour savoir si ils existent encore.
Et c'est pas un exemple theorique, c'est un soft de load balancing que j'avais ecrit sous Solaris et que j'ai du modifier de maniere assez lourde pour qu'il veuille bien tourner sous Linux, et inutile de dire que c'est bien moins performant comme methode, mais bon il n'y a pas le choix vu le bug.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 3.
- uniquement pour les priorites REALTIME
- pour des raisons precisees dans la doc(les threads de managment n'ont plus le temps de tourner si un thread de plus haute priorite monopolise le CPU trop longtemps)
- infaisable par quiconque d'autre que l'administrateur
Tout comme ecrire dans /dev/kmem peut faire torcher ta machine.
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, et son utilisation est interdite a quiconque d'autre que l'admin pour eviter les abus, maintenant si tu trouves que ce genre de choses est un bug, ben faudra penser a corriger pas mal de choses se trouvant dans /dev et dans /proc.
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.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
4 threads qui tournent.
1 thread se reveille toutes les 30 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 40 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 30 secondes, les 40 secondes et les 2 minutes 15.
1 thread se reveille toutes les 30 secondes et les 40 secondes.
J'ai beau avoir gratte la doc sur http://www.unix-systems.org/single_unix_specification_v2/xsh/thread(...)) et dans mon superbe bouquin de Richard Stevens j'ai rien vu d'evident pour faire ca, peut-etre en jouant avec des conditions et encore j'en suis pas sur du tout.
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.
Voila, tu peux aller t'amuser a modifier le handler de SIGALRM et faire un code degueu pour ca vu que les signaux sont partages par tous les threads, ou bien creer un thread qui passe son temps a recevoir les signaux et les dispatcher aux autres threads, pendant ce temps moi je cree sous Windows 3 objets timer , je leur assigne les temps, je fais WaitForMultipleObjects() dans chaque thread et c'est fini, c'est moins couteux en ressources car chaque thread n'est reveille que quand c'est necessaire et c'est plus propre a programmer. Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Si tu veux on peut aussi parler du probleme suivant:
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.
Ben avec Linux tu peux t'amuser, le PID parent du process enfant c'est le PID du thread qui a ete detruit, resultat il est impossible de le faire savoir au process grace au signal SIGCHLD et il faut faire des magouilles degueulasses genre stocker les PID des child process et faire du polling pour savoir si ils existent encore.
Et c'est pas un exemple theorique, c'est un soft de load balancing que j'avais ecrit sous Solaris et que j'ai du modifier de maniere assez lourde pour qu'il veuille bien tourner sous Linux, et inutile de dire que c'est bien moins performant comme methode, mais bon il n'y a pas le choix vu le bug.