Discussion :

[Arkey24]

Bonjour à tous!
Pour les besoins d'un projet, j'ai fait un minuteur, qui est censé fermer la fenêtre TK une fois le temps écoulé. J'ai utilisé un thread à part pour fluidifier le programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
class ThreadMinuteur(threading.Thread):
    def __init__(self,fen):
        threading.Thread.__init__(self)
        self.fen=fen
 
    def run(self):
        while self.fen.m>0:
            time.sleep(1)
            self.fen.m-=1
 
        self.fen.destroy()

Le problème arrive au niveau de la commande destroy(). En fait, la fenêtre en elle-même reste ouverte même si les boutons qui y figurent ne sont plus accessibles. Mais pour l'interpréteur, la fenêtre est bel et bien fermée (des chevrons réapparaissent une fois le temps écoulé). Je ne comprends pas vraiment ce qui se passe. J'ai creusé sur le web, mais sans succès. J'ai tenté d'isoler le thread par un lock().acquire() mais le résultat est le même.
Merci de votre aide !

[tyrtamos]

Bonjour,

Il y a longtemps que je n'ai pas travaillé avec tkinter, mais je me rappelle au moins d'une chose: tkinter n'est pas "thread-safe".

Cela veut dire que le thread ne doit pas toucher aux objets graphiques. Il faut trouver un autre moyen pour que le thread communique avec le programme principal (qui devra fermer la fenêtre dans ton cas).

[Arkey24]

Merci pour ta réponse
Je ne vois pas trop comment pouvoir communiquer avec le programme. J'avais essayé de mettre une boucle while dans la classe associée à la fenêtre, qui guettait le moment où self.m serait égal à 0. Le problème est qu'une fois entré dans la boucle, python arrête d’exécuter ce qui suit. Alors j'avais mis un autre Thread pointant vers cette boucle. Mais in fine, cela revient strictement au même. Un autre thread prend la place du premier pour achever la fenêtre.
J'avais déjà créé un minuteur en utilisant une boucle récursive. J'essayais simplement avec le thread d'éviter les gros calculs associés à fen.after()...

Sinon, il n'y a pas moyen d'utiliser un bind mais au lieu de mettre une touche du clavier, mettre quelque chose comme "self.m==0" ?

Et aussi, je suis quand même assez étonné que Python ne soit pas safe-thread, sachant que j'utilise des thread ailleurs pour déplacer automatiquement des bonhommes et aussi pour un chronomètre. Et le tout fonctionne à merveille !

[wiztricks]

Salut,

Pas besoin de threads pour faire un minuteur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
>>> import tkinter as tk
>>> def timer(left):
...     print (left)
...     if left > 0:
...        app.after(200, lambda z=left-1: timer(z))
...     else:
...        app.quit()
...
>>> app = tk.Tk()
>>> app.after(200, lambda: timer(5))
'after#0'
>>> 5
4
app.mainloop()
3
2
1
0

Pas besoin parce que la plupart des GUI fonctionnent avec une event-loop. Un GUI intègre un threading coopératif. Il suffit à traiter la plupart des cas.
Les threads systèmes sont préemptives. Elles sont indispensables lorsque le machin n'est pas "coopératif". En gros "pas coopératif", c'est ne pas arriver à libérer des cycles CPU évitant à l'utilisateur l'impression que son application est "figée". On confie alors à l'OS la responsabilité de pré-empter, libérer le CPU.

Après désolé mais tk, _tkinter,... sont "thread safe" mais çà dépend des switchs de compilation et c'est un autre sujet.

- W

[tyrtamos]

Bonjour wiztricks,

Après désolé mais tk, _tkinter,... sont "thread safe" mais çà dépend des switchs de compilation et c'est un autre sujet.

Si je résume: tkinter est thread-safe, mais ce n'est pas sûr. J'avoue que je n'aime pas beaucoup ce genre de règle. En fait, il faut au moins que tk ait été construit avec l'option " --enable-threads". Est-ce le cas? Comment le savoir?

Il existe même un projet de "tkinter-thread-safe" (http://tkinter.unpythonic.net/wiki/mtTkinter). Comme quoi le tkinter "normal" pose quelques problèmes sur ce point.

Bref, il est raisonnable de ne pas compter dessus. D'autant plus si l'on développe un programme multiplateformes.

Mais c'est dommage que ce ne soit pas clairement indiqué dans la documentation. Je n'ai rien trouvé, ni dans la doc de Python, ni dans celle de tkinter (la meilleure que je connais est celle-ci: http://infohost.nmt.edu/tcc/help/pub...web/index.html).

[wiztricks]

Mais c'est dommage que ce ne soit pas clairement indiqué dans la documentation. Je n'ai rien trouvé, ni dans la doc de Python, ni dans celle de tkinter (la meilleure que je connais est celle-ci: http://infohost.nmt.edu/tcc/help/pub...web/index.html).

Python est thread-safe. Le GIL de CPython rend la plupart des changements sur les objets builtins tels que list, dict,... sont thread-safe. Mais dans la pratique, on évitera de créer des threads pour rien.
Le cas échéant on sérialisera l'accès aux objets partagés par des verrous.
Si on la joue aussi "parano", c'est parce qu'on sait que les "bugs" seront difficiles à reproduire, corriger,... même si la cause est due à une mauvaise utilisation/bug de la biblio.

- W

[Arkey24]

Merci pour vos réponses !
J'ai finalement rebasculé sur le minuteur avec self.after() comme le proposait Wiztricks.

[wiztricks]

J'ai finalement rebasculé sur le minuteur avec self.after() comme le proposait Wiztricks.

Super.
Plus besoin de se prendre le chou avec thread-safe ou pas, avec ce threading coopératif la sérialisation d'accès est "builtin" et bien plus facile à contrôler. Et ne parlons pas des performances/Watt.
- W