Méthode _Thread__stop deprecated en python 3.2

bonsoir,

Il semble qu'en python 3.2 la méthode

Code:

---

_Thread__stop()

---

qui permettait de tuer un thread (module threading) soit "en disgrâce à la cour".

Quelqu'un saurait-t-il quelle est sa remplaçante ?
Ni la doc python ni google ne sont très verbeux.
J'ai bien trouvé cela:
http://pydoc.org/2.2.3/threading.html

mais,

Code:

---

__stop(self)

---

ne fonctionne pas...

Merci

Salut,
Les méthodes qui commencent par _ ou __ et qui ne sont pas documentées ne sont pas sensées être utilisées.
Rien ne vous empêche d'aller lire les sources pour constater que le __stop a été remplacer par _stop...., ceci dit, le code ne fait peut être pas ce que vous voulez, car:

Code:

---

1 2 3 4 5

def _stop(self): self._block.acquire() self._stopped = True self._block.notify_all() self._block.release()

---

change l'état du thread mais ne sort pas de la méthode _run: vous avez l'impression que la thread est 'stop' mais elle continue de tourner.
- W

Citation:

---

le code ne fait peut être pas ce que vous voulez

---

J'en déduis d'une part, qu'il y a régression entre python 2.7 et 3.2.

d'autre part que la FAQ de ce site
http://python.developpez.com/faq/?pa...ead#ThreadKill
est à mettre à jour à ce niveau.

Comment stopper un thread bloqué sur un appel système ne gérant pas les time-out ?

Citation:

---

Comment stopper un thread bloqué sur un appel système ne gérant pas les time-out ?

---

Il n'y a pas de signal qui permette de faire sortir la thread du 'run' et donc de l'appel système... la méthode _stop ne permet pas de faire çà, elle vous donne juste l'illusion que çà l'a fait.
Pour le cas général, il faut être pragmatique: fork, spawn,... en fonction de...
- W

Dois-je en déduire que les process (bien que plus lourds) sont préférables aux threads si on désire la fonction "suppression" ?

Bonjour,

J'ai étudié quelques moyens pour arrêter les threads: http://python.jpvweb.com/mesrecettes...d=arret_thread, mais rien d'aussi solide qu'une méthode prédéfinie.

Côté process, il faut regarder le module multiprocessing: il traite les process un peu comme les threads, y compris avec des partages de données. mais il y a un moyen de les arrêter (terminate). C'est un peu brutal, mais ça marche.

Tyrtamos

Citation:

---

Envoyé par Bayard

Dois-je en déduire que les process (bien que plus lourds) sont préférables aux threads si on désire la fonction "suppression" ?

---

La "suppression" a des implications qu'il faut apprécier correctement.

Une des difficultés de toute solution générale est de réaliser que 'threads' signifient un état global (le même espace d'adressage) partagé entre plusieurs contextes d'exécution.

Supprimer un de ces contextes de façon arbitraire peut laisser l'état global inconsistant rendant préférable le redémarrage de l'application. Pour éviter cela, la suppression doit être signalée au thread pour qu'elle puisse 'nettoyer' et non imposée...

Dit autrement, le run doit pouvoir ressembler à:

Code:

---

1 2 3 4 5

def run (self): try: # boulot de la thread except InterruptError: # nettoyage

---

1 => le "boulot de la thread" doit être "interruptible", ce qui n'est pas le cas de tous les appels systèmes.

Comment réaliser InterruptError?

Python n'est pas Java i.e. on n'écrit pas une VM qui réalise une abstraction d'OS indépendamment de ceux-ci mais basée sur les fonctionnalités qu'on retrouvera sur tout les OS. Et comme les fonctionnalités des API des signals ne sont pas homogènes, InterruptError n'est pas là.

Note: vous avez néanmoins, en général, la possibilité d'interrompre le tread principal,, genre:

Citation:

---

thread.interrupt_main()¶

Raise a KeyboardInterrupt exception in the main thread. A subthread can use this function to interrupt the main thread.

---

Avec des process séparés, vous avez les signaux de type kill,... qui sont en général disponibles partout mais si vous passez par multiprocessing par exemple, vous avez construit un état 'global'....
On sait réaliser InterruptError (via p.terminate) mais le boulot de nettoyage reste à faire...

Ce boulot de nettoyage sera fonction des dépendances entre les différents contextes d'exécutions: si vous voulez être sûr de garantir la consistance de l'état global et des différents contextes qui devront "survivre", il faudra les limiter au moins pour celles qui dépendront des appels systèmes ou à une bibliothèque particulière....
Vous vous rabattrez rapidement sur un modèle client/serveur: les appels seront effectués dans le contexte de serveurs dédiés à cela.
Un main thread peut être signalé, la thread principale d'un programme multithread est généralement un bon candidat... d'autant que les appels "génants" sont rarement ré-entrants.

- W