255 votes

Explication des fils Daemon

Dans le Documentation Python il est dit :

Un thread peut être marqué comme étant un "thread démon". La signification de ce est que l'ensemble du programme Python se termine lorsque seuls les threads démoniaques sont laissés. La valeur initiale est héritée du thread créateur.

Est-ce que quelqu'un a une explication plus claire de ce que cela signifie ou un exemple pratique montrant où l'on peut définir les fils en tant que daemonic ?

Clarifiez pour moi : donc la seule situation où vous ne définissez pas les fils en tant que daemonic C'est quand vous voulez qu'ils continuent à fonctionner après la sortie du fil principal ?

485voto

Chris Jester-Young Points 102876

Certains threads effectuent des tâches d'arrière-plan, comme l'envoi de paquets keepalive, ou la collecte périodique des déchets, ou autre. Ces tâches ne sont utiles que lorsque le programme principal est en cours d'exécution, et il n'y a pas de problème à les tuer une fois que les autres threads, non-démons, sont sortis.

Sans les threads démons, vous devriez en garder la trace et leur dire de se retirer, avant que votre programme puisse se terminer complètement. En les définissant comme des threads démons, vous pouvez les laisser s'exécuter et les oublier, et lorsque votre programme se termine, tous les threads démons sont tués automatiquement.

1 votes

Donc, si j'ai un thread enfant qui effectue une opération d'écriture de fichier et qui est défini comme non-deamon, cela signifie-t-il que je dois le faire sortir explicitement ?

8 votes

Que fait votre fil d'écriture une fois qu'il a fini d'écrire ? Est-ce qu'il revient simplement ? Si oui, c'est suffisant. Les threads démons sont généralement destinés à des choses qui tournent en boucle et ne se terminent pas d'elles-mêmes.

0 votes

Il ne fait rien, ne renvoie rien, son seul but est d'effectuer une opération d'écriture de fichier.

31voto

John Fouhy Points 14700

Disons que vous faites une sorte de widget de tableau de bord. Dans ce cadre, vous voulez qu'il affiche le nombre de messages non lus dans votre boîte aux lettres électronique. Vous créez donc un petit fil qui :

  1. Connectez-vous au serveur de messagerie et demandez combien de messages non lus vous avez.
  2. Signalez à l'interface graphique le compte mis à jour.
  3. Dors un peu.

Lorsque votre widget démarre, il crée ce fil de discussion, le désigne comme un démon et le lance. Comme il s'agit d'un démon, vous n'avez pas à y penser ; lorsque votre widget se termine, le fil s'arrête automatiquement.

18voto

Jonathan Points 1032

Une façon plus simple d'y penser, peut-être : lorsque main revient, votre processus ne se terminera pas s'il y a des threads non-daemon encore en cours d'exécution.

Un petit conseil : Il est facile de se tromper dans un arrêt propre lorsque des threads et la synchronisation sont impliqués - si vous pouvez l'éviter, faites-le. Utilisez des threads de démon chaque fois que c'est possible.

0 votes

Un autre commentaire contient ceci : D'autres posters ont donné quelques exemples de situations dans lesquelles vous utiliseriez des threads de démon. Ma recommandation, cependant, est de ne jamais les utiliser. Sa suggestion ou votre suggestion est-elle plus correcte pour Python 3 ?

18voto

Joe Shaw Points 6386

D'autres posters ont donné quelques exemples de situations dans lesquelles vous utiliseriez des threads de démon. Je recommande toutefois de ne jamais les utiliser.

Ce n'est pas parce qu'ils ne sont pas utiles, mais parce qu'il y a de mauvais effets secondaires que vous pouvez ressentir si vous les utilisez. Les threads démons peuvent continuer à s'exécuter après que le runtime Python a commencé à démolir les choses dans le thread principal, ce qui provoque des exceptions assez bizarres.

Plus d'informations ici :

https://joeshaw.org/python-daemon-threads-considered-harmful/

https://mail.python.org/pipermail/python-list/2005-February/343697.html

Strictement parlant, vous n'en avez jamais besoin, cela facilite simplement la mise en œuvre dans certains cas.

0 votes

Toujours ce problème avec python 3 ? Il n'y a pas d'informations claires concernant ces "exceptions bizarres" dans la documentation.

5 votes

Extrait de l'article du blog de Joe : "Mise à jour de juin 2015 : Ceci est Bug de Python 1856 . Il a été corrigé dans Python 3.2.1 et 3.3, mais le correctif n'a jamais été rétroporté en 2.x. (Une tentative de rétroportage vers la branche 2.7 a provoqué un autre bogue et a été abandonnée). Les Daemon threads peuvent être acceptés dans Python >= 3.2.1, mais ne le sont certainement pas dans les versions antérieures."

0 votes

J'aimerais partager ici mon expérience : J'avais une fonction spawned en tant que Thread plusieurs fois. A l'intérieur de celle-ci, j'avais une instance de Python logging et je m'attendais à ce que, après avoir terminé le Thread, tous les objets (descripteurs de fichiers pour chaque Thread/Fonction), soient détruits. A la fin de mon programme, j'ai vu beaucoup de sorties comme IOError: [Errno 24] Too many open files: . Avec lsof -p pid_of_program J'ai découvert que les FDs étaient ouverts, même si les Thread/Functions avaient terminé leur travail. Solution ? En supprimant le gestionnaire de journal à la fin de la fonction. Donc daemonic Les fils, ne sont pas dignes de confiance...

11voto

Bass Points 28

Citation de Chris : "... lorsque votre programme s'arrête, tous les threads du démon sont tués automatiquement.". Je pense que cela résume bien la situation. Vous devez être prudent lorsque vous les utilisez car ils se terminent brusquement lorsque le programme principal s'exécute jusqu'à la fin.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X