Je préfère malgré tout l'approche gobject.idle_add().
Pourquoi pas. Mais comme je pensais que ton but était de pouvoir faire des appels gtk depuis un autre thread, je ne voyais pas pourquoi tu l'utilises.
Par contre, le idle_add() ne te dispense pas de bien locker les accès/écritures aux données de ton thread, car c'est le thread principal qui exécutera le code à ce moment-là.
C'est une question de préférence personnelle, peut-être, mais la plupart des bibliothèques graphiques n'autorisent pas les appels cross-thread, même avec des verrous.
Oui, effectivement, ce n'est pas forcément préconisé, mais c'est possible avec gtk.
D'ailleurs, que se passe-t-il si une exception est levée entre threads_enter() et threads_leave() ?
Tu mets ton leave() dans le finally:, comme indiqué dans le lien que tu donnes en dessous.
Pour préserver les espaces dans le code, utilise des balises . Lis la doc ;-)
[^] # Re: Une solution
Posté par benoar . En réponse au message PyGTK et les threads.. Évalué à 2.
Pourquoi pas. Mais comme je pensais que ton but était de pouvoir faire des appels gtk depuis un autre thread, je ne voyais pas pourquoi tu l'utilises.
Par contre, le idle_add() ne te dispense pas de bien locker les accès/écritures aux données de ton thread, car c'est le thread principal qui exécutera le code à ce moment-là.
C'est une question de préférence personnelle, peut-être, mais la plupart des bibliothèques graphiques n'autorisent pas les appels cross-thread, même avec des verrous.
Oui, effectivement, ce n'est pas forcément préconisé, mais c'est possible avec gtk.
D'ailleurs, que se passe-t-il si une exception est levée entre threads_enter() et threads_leave() ?
Tu mets ton leave() dans le finally:, comme indiqué dans le lien que tu donnes en dessous.
Pour préserver les espaces dans le code, utilise des balises . Lis la doc ;-)
Arf, bien vu ... Merci ;-)