estelle a écrit : ↑sam. 13 mars 2021 11:42
J'ai testé cela:
Mouais ... c’est le probleme des mauvais exemples, ça donne des mauvaises idées ...
Tu peux enlever l’évaluation T1. Is.alive(). Elle ne sert à rien pour la simple et bonne raison que T1 est forcément alive et c’est bien là le problème. Tout comme dans l’exemple cité, tu utilises une boucle sans condition explicite de sortie dans ton thread. Ça, quel que soit le langage utilisé et quoi que fasse ce thread, c’est la pire chose que tu puisses faire et je ne comprend meme pas que personne ne réagisse à ça (ça en dit long sur le niveau des intervenants …). A partir du moment où tu fais ça tu te condamnes à ne pas pouvoir arrêter ton thread secondaire autrement qu’en le tuant arbitrairement sans aucun contrôle sur son point de sortie. Dans l’exemple cité, le mec n’est meme pas conscient de ça puisque la seule sortie du programme qu’il a prévue c’est le shutdown, ce qui résout très facilement le probleme d’un programme qui se plante
Pour juste comprendre, mets texto le code que tu as posté dans un fichier .py et démarre-le . Puis quitte le en faisant un ctrl+c. Tu verras que ça ne te rendra pas la main et que ‘T1 is actif’ ne s’affichera plus. En revanche ça continuera de t’afficher les sorties écrites par T1. Si tu es en mode desktop et que tu as lancé ça dans une fenêtre console, il suffit de fermer la fenêtre pour tuer le process. Par contre si tu es en mode console et que tu n’as pas la possibilité de te connecter pour ouvrir une autre console pour faire un kill sur le process, le seul moyen de l’arrêter sera de rebooter.
Si tu veux utiliser un thread comme tu le fais, remplace au moins le ‘true’ dans le while de T1 par un boolean de portée globale. De la sorte, dans la procédure de sortie de ton programme tu peux remettre cette variable à false suivi d’un T1.joint(). C’est de la méthode de débutant, mais au moins tu auras la certitude que T1 sera terminé avant la fin du thread principale. C'est la base fondamentale du fonctionnement propre du multithreading. Tous les threads secondaires doivent etre terminés avant la fin du thread principale. Si cette règle n'est pas respectée => code poubelle !
Une autre chose. Tu parles d’interruption sur évènement. Déjà, il y a là-dedans2 concepts. Interruption est une chose, évènement en est une autre, mais … c’est sans importance ici. Je ne sais pas ce que tu veux faire au final, mais supposons que tu veuilles juste piloter un ventillo quand le cpu dépasse une certaine temperature : La, tu as 2 choix :
1 – Tu mets le code de pilotage du ventillo dans ton thread T1 (enfin .. Après l’avoir codé correctement …). Dans ce cas, il n’y a pas d’évènement, c’est ton thread T1 qui va gérer ça dans son coin sans aucune interaction avec le thread pricipal. C’est loin d’etre la meilleure méthode, mais ça reste ce qu’il y a de plus simple et pour une bricole, ça peut suffire.
2 – Tu code ton thread T1pour qu'il lève un évènement dans ton programme principal en cas de dépassement de temperature. Dans ce cas tu peux coder une fonction dans le thread principal pour piloter le ventillo. Ça c’est beaucoup plus propre puisque ça minimise le code exécuté dans T1 et ça empêche tout probleme de concurrence (partage de ressource commune entre les 2 threads). Ça c’est la bonne méthode mais forcement c’est beaucoup plus compliqué surtout avec un langage comme python…
Bon avec tout ça, j’ai loupé le thread de l’apéro moi
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).