Bonjour, je bosse sur un même programme depuis longtemps, et je suis tombé sur une exception... bizarre. Il n'y a aucune explication "Pythonesque", j'espère que vous pourrez m'éclairer dessus.
Merci d'avance.
Version imprimable
Bonjour, je bosse sur un même programme depuis longtemps, et je suis tombé sur une exception... bizarre. Il n'y a aucune explication "Pythonesque", j'espère que vous pourrez m'éclairer dessus.
Merci d'avance.
Bonjour,
pas facile de répondre avec aussi peu de détails...
Tu pourrais nous donner l'extrait du code autour des lignes 223 et 1038.
Tu pourrais aussi regarder le rapport d'erreur de microsoft (en cliquant sur le "cliquer ici").
Tu as peut-être trop de threads qui tournent en même temps sur ta machine...
Le système n'en supporte qu'un nombre limité (mais grand).
La ligne 1038, c'est tkinter. J'ai 2 ou 3 threads qui tournent mais le problème doit venir des sockets : j'ai une connexion sur laquelle j'envois un million d'octets tous les quarts de seconde. Au bout de 4 secondes, ça plante sur le receveur des données. (le serveur dans mon cas)
Comment faire dans ce cas ? j'envois mes données alternativement sur plusieurs ports ?
Bonjour,
Une idée. Je n'ai pas vu le code, mais comme je lis les mots "tkinter", "thread" au sujet d'un crash, je me dis que tkinter n'est pas thread-safe". Autrement dit, il ne faut pas avoir d'instruction graphique dans les threads.
Ah, je ne savais pas. Il y a en effet la modification d'un widget Canvas et également une boucle mainloop (pour que la fonction ne soit pas bloquante).
Pourtant dans un autre programme les deux marchent très bien (je prends comme exemple le script qui affiche le flux de la webcam, dans contribuez)
Si c'est une question de cohabitation entre threads et GUI, les plantages dépendent de "race conditions". C'est comme au loto: on ne gagne pas a tous les coups.Citation:
Envoyé par stalacta
- W
Par défaut, tkinter doit tourner sur le thread principal.
Une solution ?
http://code.activestate.com/recipes/...safetkinterpy/
mais vu la note, pas sur que ça marche ... peut être vaut il mieux passer tkinter sur le main thread et locker convenablement ?
Bonjour,
Avec les bibliothèques graphiques, souvent "non-thread-safe", il n'est pas toujours facile d'utiliser les threads lorsqu'il doivent avoir un effet sur le graphique (mise à jour d'une barre de progression par exemple).
Il ya longtemps que je n'ai pas utilisé tkinter, mais je crois que le plus courant est d'assurer une communication avec une variable de type Queue (module Queue) qui est thread-safe. Cela nécessite de la part du graphique une surveillance de l'état de cette variable, afin de déclencher au bon moment les actions graphiques prévues.
Avec PyQt, on a une autre solution. En utilisant une classe QThread, le thread devient capable d'envoyer des messages au graphique, chacun de ces messages lançant automatiquement à réception l'exécution d'une méthode graphique. C'est donc dans ce cas la boucle de traitement des évènements qui surveille et permet la communication entre le thread et l'IHM.
Ce n'est pas spécifique au bibliothèques graphiques.Citation:
Envoyé par tyrtamos
Des qu'on a plusieurs threads qui doivent échanger des informations, ça passe toujours par un protocole d'envoi de messages et un mécanisme de sérialisation.
Tk et Qt sont construits de la même façon: une eventloop qui dépile les événements qui déclenchent des callbacks. A partir de la, on peut utiliser l'eventloop comme "support" a la mécanique d'envoi de messages.
Après, ce n'est que "détails" de mise en œuvre avec Qt on passera in fine par la methode .postEvent, avec Tk ce sera .after_idle.
On a besoin de "plus" pour réaliser des appels de fonctions i.e. récupérer ce qui a été retourne par l’exécution du "message" dans le contexte de la thread appelée - ce qui est une mauvaise idée dans le cas général.
- W