comment killer un thread en python?

comment killer un thread en python? - Python - Programmation

Marsh Posté le 20-10-2003 à 17:54:25    

En Java lorsque l'on cree un thread on peut le killer simplement a partir du processus pere.
 
Par contre en python j'ai l'impression que ce n'est pas possible.
Dans http://www.python.org/doc/current/ [...] jects.html, pas la moindre fonction du style killThread.
 
Comment faire pour m'en sortir?
 
merci de vos conseils.
 
 
 
 

Reply

Marsh Posté le 20-10-2003 à 17:54:25   

Reply

Marsh Posté le 20-10-2003 à 17:58:26    

Chriss a écrit :

En Java lorsque l'on cree un thread on peut le killer simplement a partir du processus pere.


sauf que c'est déprécié depuis perpette.
 
tu étends Thread, et tu rajoutes ta fonction pour quitter, ce qui permet d'assurer un état cohérent.

Reply

Marsh Posté le 21-10-2003 à 09:43:25    

Tu parles d'une fonction interne a mon thread?  
 
Elle ressemble a quoi cette fonction pour quitter?  
 

Reply

Marsh Posté le 21-10-2003 à 09:47:20    

ca depends de ce a quoi ressemble ton thread [:spamafote]
 
exemple :

Code :
  1. class MonThread(Thread):
  2.   def run(self):
  3.     self.running = True
  4.     while self.running:
  5.       #blabla
  7.   def stop(self):
  8.     self.running = False

Reply

Marsh Posté le 21-10-2003 à 11:50:26    

lorill a écrit :

ca depends de ce a quoi ressemble ton thread [:spamafote]
 
exemple :

Code :
  1. class MonThread(Thread):
  2.   def run(self):
  3.     self.running = True
  4.     while self.running:
  5.       #blabla
  7.   def stop(self):
  8.     self.running = False




 
Ouep !
Faut aussi penser a stocker ces objets Threads quelque part.
Enfin moi c'est comme ca que je fais :)

Reply

Marsh Posté le 22-10-2003 à 10:13:08    

Je pense que ton thread reste present quand tu fait comme ca.
sa boucle est arrete mais il continue a etre la.
 
J'ai trouvé une bonne solution a cette adresse:
http://aspn.activestate.com/ASPN/C [...] cipe/65222
 
De cette facon je kill proprement mes threads

Reply

Marsh Posté le 23-10-2003 à 12:42:21    

Chriss a écrit :

Je pense que ton thread reste present quand tu fait comme ca.
sa boucle est arrete mais il continue a etre la.
 
J'ai trouvé une bonne solution a cette adresse:
http://aspn.activestate.com/ASPN/C [...] cipe/65222
 
De cette facon je kill proprement mes threads
 


Je pense pas...
Puisqu'il quitte la methode run() [:spamafote]


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Reply

Marsh Posté le 18-12-2003 à 23:29:26    

Salut,
 
Je rallume ce topic car je bute précisément sur ce problème.
 
J'ai une thread qui tourne en while 1 donc je ne peux pas déclencher d'action à partir d'elle, il faudrait que je la kill de la thread principale et je vois pas trop comment m'y prendre.
 
merci d'avance

Reply

Marsh Posté le 18-12-2003 à 23:34:24    

toutes façons c'est chiant de pas pouvoir tuer, si ton bordel est bloqué (attente de ressource : E/S, verrou, etc), t'es bien dans la merde
 
pthread_cancel :love:

Reply

Marsh Posté le 18-12-2003 à 23:40:15    

En effet c'est chiant qu'il n'y ait pas de moyen simple pour faire ça.

Reply

Marsh Posté le 18-12-2003 à 23:40:15   

Reply

Marsh Posté le 18-12-2003 à 23:40:46    

y a pas de moyen du tout en fait

Reply

Marsh Posté le 18-12-2003 à 23:42:42    

C'est ce que j'étais entrain de comprendre là.

Reply

Marsh Posté le 18-12-2003 à 23:53:12    

moi aussi je trouve ça dommage. quand on voit l'intelligence des pthread notemment avec la gestion des points d'interruption, les routines de nettoyage, c'est une véritable régression.

Reply

Marsh Posté le 19-12-2003 à 00:02:41    

Mais mon problème est vraiment bizarre. Le fait que je ne puisse pas killer cette thread fait que à la destruction de l'objet dans lequel est crée la thread, mon __del__ ne se lance pas.  Ca marche très bien si je ne lance pas la thread.

Reply

Marsh Posté le 19-12-2003 à 00:05:34    

c'est normal. donne le code quand même.

Reply

Marsh Posté le 19-12-2003 à 00:12:36    

Sans compter que l'interpréteur CPython (je ne sais pas pour Jython) a un "global lock", c'est à dire que 2 threads python ne s'exécutent pas vraiment concurremment, même sur machine multi-CPU. (Sauf lors des appels à des fonctions natives non interprétées si le mutex est lâché)


Message édité par verdoux le 19-12-2003 à 00:12:56
Reply

Marsh Posté le 19-12-2003 à 00:12:40    

J'ai reproduit le problème ici :  
 

Code :
  1. #!/usr/bin/python
  2. import thread
  3. import time
  5. class Prout:
  6. def __init__(self):
  7.  nothing =()
  8.  print 'prout'
  9.  thread1 = thread.start_new_thread(self.fonc,nothing)
  11. def __del__(self):
  12.  print 'goodbye!'
  14. def fonc(self):
  15.  while(1):
  16.   time.sleep(1)
  17.   print "yo"
  19. pr = Prout()
  20. time.sleep(5)
  21. del pr


 
le destructeur ne s'execute pas.


Message édité par chaica le 19-12-2003 à 00:14:31
Reply

Marsh Posté le 19-12-2003 à 00:15:44    

1) utilise threading
2) c'est normal, del n'appelle __del__ que si il n'y a plus de référence. or ici, le thread référence ton Prout via self.fonc

Reply

Marsh Posté le 19-12-2003 à 00:19:56    

1) je vais voir ça
2) yep je suspectais cette finesse.
3) bon c'est chiant, faut que je trouve une feinte... :)

Reply

Marsh Posté le 19-12-2003 à 10:32:26    

Perso je trouve que c'est plus propre de passer par un héritage Thread, mais bon...
Sinon Taz a raison pour le problème de référence.
Une soluce possible :

Code :
  1. import thread
  2. import time
  4. class Prout:
  5.     def __init__(self):
  6.         nothing =()
  7.         self.continu = True
  8.         print 'prout'
  9.         thread1 = thread.start_new_thread(self.fonc,nothing)
  11.     def stop(self):
  12.         self.continu = False       
  13.        
  14.     def __del__(self):
  15.         print 'goodbye!'
  16.        
  17.     def fonc(self):
  18.         while(self.continu):
  19.             time.sleep(1)
  20.             print "yo"
  21.      
  22. pr = Prout()
  23. time.sleep(5)
  24. pr.stop()
  25. time.sleep(2)
  26. del pr


 
le time.sleep(2) est la pour compenser le time.sleep(1) dans fonc() qui empeche le thread de se terminer avant l'appel a del

Reply

Marsh Posté le 19-12-2003 à 13:37:09    

pas la peine de mettre le del ...

Reply

Marsh Posté le 19-12-2003 à 14:47:12    

Bah si, c'est pour illustrer que l'appel a del est pris en compte lorsque le thread est sorti de sa boucle...

Reply

Marsh Posté le 19-12-2003 à 18:16:25    

e_esprit a écrit :

Bah si, c'est pour illustrer que l'appel a del est pris en compte lorsque le thread est sorti de sa boucle...

bah quand l'interprétyeur termine, il détruit le thread

Reply

Marsh Posté le 20-12-2003 à 23:13:26    

Je parle pas de la destruction effective du thread mais de l'appel a __del__


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Reply

Marsh Posté le 20-12-2003 à 23:16:06    

et quoi ?
lis la documentation du gc, vois le fonctionnement de del

Reply

Marsh Posté le 21-12-2003 à 12:10:41    

:heink: je crois que t'as pas bien compris ce que je disais...
L'exemple fourni illustre ce que tu disais :

Citation :

1) utilise threading
2) c'est normal, del n'appelle __del__ que si il n'y a plus de référence. or ici, le thread référence ton Prout via self.fonc


Alors faut pas s'ennerver, hein... reste zen !


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Reply

Marsh Posté le 21-12-2003 à 12:57:06    

moi je comprends pas ce dont tu parles

Reply

Marsh Posté le 21-12-2003 à 15:40:43    

Bah relis a partir de la
Apres si tu comprends toujours pas, je peux plus rien pour toi...


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Reply

Marsh Posté le 21-12-2003 à 15:43:07    

garbage
    A list of objects which the collector found to be unreachable but could not be freed (uncollectable objects). By default, this list contains only objects with __del__() methods.3.1Objects that have __del__() methods and are part of a reference cycle cause the entire reference cycle to be uncollectable, including objects not necessarily in the cycle but reachable only from it. Python doesn't collect such cycles automatically because, in general, it isn't possible for Python to guess a safe order in which to run the __del__() methods. If you know a safe order, you can force the issue by examining the garbage list, and explicitly breaking cycles due to your objects within the list. Note that these objects are kept alive even so by virtue of being in the garbage list, so they should be removed from garbage too. For example, after breaking cycles, do del gc.garbage[:] to empty the list. It's generally better to avoid the issue by not creating cycles containing objects with __del__() methods, and garbage can be examined in that case to verify that no such cycles are being created.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed