IHM qui freeze lors d'utilisation subprocess

Bonjour à tous,

Je suis en train de travailler sr la V2.0.0 de mon logiciel Open Source PYXMAKER.

Je suis confronté à un petit soucis pour lequel je n'ai pas vraiment trouvé de solution et pour lequel je sollicite votre aide.

Ce logiciel permet d'automatiser et simplifier la generation de standalone windows et de setup d'install, via IHM, à partir de code source python via un interfacage avec cx_freeze et inno setup.

Tout se passe de manière graphique, plus de script à créer. Lors de la validation (bouton du dernier ecran, puis bouton de la fenetre pop up qui suit), l'IHM se fige.

Lors de cette validation, j'appelle une fonction qui fait d'abord appel à cx_freeze, puis à inno setup. Pour ces appels, j'utilise subprocess.popen. Pour etre sur que ces taches s'exécute de manière procedurale, j'utilise egalement un subprocess.wait.

Le probleme est que cela freeze mon IHM, normal me direz vous, on attend la fin de l'execution des commande avant de rendre la main à l'IHM.

La solution est d'appeler cette fonction dans un thread séparé de mon thread normal, puis de capturer la fin de ce thread parallele afin d'avertir l'utilisateur.

Jusqu'ici je n'ai pas reussi (utiliser de threading.thread), d'ou ce post.

Les sources sont en PJ, si certaines personnes veulent regarder de plus près. J'ai également joint un autre de mes logiciels pour avoir un exemple de sources compatibles (un certains formalisme est obligatoire pour que pyxmaker fonctionne).

Merci beaucoup d'avance.

EDIT: l'appel se fait dans ihm_pyxmaker.py, aux alentour de la ligne 1690 (rtr = ...)

Bonjour,

Si tu avais choisi PyQt4, je t'aurais proposé la solution suivante. Peut-être y a-t-il l'équivalent en PyGtk:

- utiliser QThread plutôt que threading pour permettre l'échange de messages
- faire que le thread envoie un message de fin à l'ihm
- le message de fin reçu par l'ihm exécute la méthode prévue dans ce cas
- ce message peut porter des données Python pour permettre à l'ihm de récupérer des résultats.

Attention: dans la plupart des bibliothèques graphiques, il n'est pas permis aux threads de toucher directement au graphique. D'où l'échange de messages.

En faisant comme ça, l'ihm n'est jamais figé pendant l'exécution du thread.

A noter qu'avec threading, il y a aussi une solution: au lieu de bloquer l'ihm en attendant que le thread se termine, on peut tester périodiquement si le thread est toujours en vie avec "isAlive".

Bonjour Tyrtamos,

Je ne connaissais pas isAlive. Je vais chercher de ce coté du coup. Merci beaucoup :ccool:

Je reviens d'ici de midi pour poster mes resultats de test

Salut,

Tu ne dis pas pourquoi tu n'es pas parvenu à lancer subprocess dans un thread, quel problème cela présentait il ?

Bonjour VinsS,

En fait j'ai eu deux cas: ou le code de l'appel ne s’exécutait pas, ou bien j'avais des messages d'erreurs divers et variés (je ne me rappelle plus lesquels).

Quoiqu'il en soit, cela ne fonctionnait pas. Apres pas mal d'essais, je me suis alors decidé à demander un peu d'aide et conseils.

EDIT:
En fait ce que j'ai actuellement c'est (grosso modo) ceci:
--Appel de ma fonction
--Freezage IHM jusqu'à fin fonction
--Execution du code qui suit

Ce que je desirerais obtenir au final
--Appel de ma fonction en parallèle
--L'IHM continue normalement, quand la fonction à fini, elle execute une fonction dans le code de l'IHM (declenchement d'une exeption,MAJ d'une variable, ...)

Juste un petit complément pour utiliser isAlive dans une ihm.

Une ihm est pilotée par une boucle qui traite les instructions (messages, évènements, ...) en attente quand il y en a.

Avec PyGtk, il devrait y avoir une méthode qu'on peut appeler dans le code de l'ihm et qui lui dit: "exécuter les instructions en attente, et revenez quand il n'y en a plus".

Si c'est le cas, voilà comment faire juste après le code qui a lancé le thread:

Code:

---

1 2 3 4

while monthread.isAlive(): execinstructionsihm()   # ici, le thread a terminé son boulot: on peut faire la suite

---

Avec ça, l'ihm n'est pas figé, et on sait quand le thread se termine.

Salut,

Les échanges d'informations entre des threads et celle du GUI se font sur les mêmes principes: seuls les détails d’implémentation changent.
Mais l'enfer est dans ces détails.

Pour PyGTK, ces détails sont "documentes" dans les FAQ.

Bonne lecture
- W

Merci beaucoup à vous tous,

wiztricks, ton lien m'a beaucoup aidé, je le recommande. Échanger avec vous tous m'a permis d'appréhender mon probleme sous d'autres angles.

J'ai donc fini par trouver la solution. J'ai oublié ma clé sur mon pc au taf. Je post donc la solution demain et passerai le post en resolu avec des explications

A demain, et merci

Comme promis, voici la solution. Les fichiers sont en PJ.

Comme dans le lien donné par Wiztricks, il s'avère qu'il y a une manière de procéder avec les threads en pygtk.

Dans le fichier de l'IHM il faut donc rajouter un "import gobject" et un "import thread". Ensuite dans l'init de la classe IHM, on ajoute "gobject.threads_init()".

On lance le traitement désiré en parallèle avec "self.test = thread.start_new_thread(self.fct_gener_setup, (self.dico_param,self.p_print_result))" (dans mon cas). ici self.p_print_result est la fonction qui sera appelée par self.fct_gener_setup lorsqu'elle aura fini.

Dans cette fonction, on utilisera "gobject.idle_add()" pour executer des commandes en dehors du thread parallèle.

Les fonctions impactée sont p_print_result(creation), p_win_confirm_response(modification), __init__(modification) et les imports dans ihm_pyxmaker.py, et p_mk_cxf(modification) dans pyxmaker.py

Voilà pour les explications. Merci beaucoup à tous pour votre aide :ccool:

Sujet resolu