Content que ça t’ai aidé :)
]]>J’ai mis un timeout court à la lecture du retour de mon process et je boucle sur la fonction read() de pexpect:
c=pexpect.spawn(ma_commande_qui_renvoie_16_Mo_de_texte_en_50sec)
c.timeout=0.2
res="nada"
while res=="nada":
try:
res=c.read()
except pexpect.TIMEOUT:
print "Wait...or do something else!"
J’en profite pour dire que les infos qui accompagnent l’exception TIMEOUT du module ‘pexpect’ sont super riches et permettent de voir si votre process est freezé en affichant les 100 dernier caractères du buffer de sortie.
Merci pour le tuyau Max!
]]>t’as essayé Pexpect et la doc ici ?
Je ne connais pas envoy, j’utilise pexpect depuis quelques temps que je trouve pas mal.
]]>En utilisant le module ‘signal’, on peut intercepter la fin du process et éviter ça…mais pas directement avec ‘envoy’, qui semble être à l’abandon.
Ça me parait trop gros pour un langage si habituellement parfait qu’est python! On a le PID, je comprend pas qu’on puisse pas intercepter le signal de fin de process avec Popen alors qu’on l’a facilement via un wait()….je me demande si c’est pas un vieux bug qui a été résolu depuis ou si c’est lié à ma plateforme (je suis en 2.6 sous Solaris…et ouais, je suis au boulot!).
Je ferais d’autres test chez moi et si je trouve un moyen, je ferais tourner l’info!
]]>En fait, le pb semble venir de subprocess.Popen…j’arrive à dégager le process zombie en faisant un p._process.wait() (p étant mon objet envoy.ConnectedCommand) ou un os.wait(), mais du coup, je ne récupère jamais le résultat de ma commande.
Est-ce que ça vous parle, Ô grands mages du python?
(désolé d’être HS, mais une occasion de parler envoy.connect, je pouvais pas rater ça!)
]]>