Le blocage et Non de Blocage sous-processus des appels

Je suis complètement confus entre subprocess.call() , subprocess.Popen(), subprocess.check_call().

Qui bloque et qui ne l'est pas ?

Ce que je veux dire est que si j'utilise subprocess.Popen() si le processus parent attend pour le processus de l'enfant à return/exit avant de les conserver sur son exécution.

Comment shell=True affecter ces appels?

  • avez-vous essayé subprocess.call([cmd,params,&])?
InformationsquelleAutor Roshan Mehta | 2014-02-21
  1. 79

    Popen est non bloquante. call et check_call sont de blocage.
    Vous pouvez faire la Popen instance de bloc en appelant ses wait ou communicate méthode.

    Si vous regardez dans le code source, vous verrez call appels Popen(...).wait(), c'est pourquoi il est bloquant.
    check_call appels call, c'est pourquoi il bloque ainsi.

    À proprement parler, shell=True est orthogonal à la question de blocage. Cependant, shell=True causes Python à un shell exec, puis exécutez la commande dans le shell. Si vous utilisez un blocage de l'appel, l'appel sera de retour lors de la shell finitions. Depuis le shell peut générer un sous-processus de l'exécution de la commande, le shell peut se terminer avant la donné naissance à un processus secondaire. Par exemple,

    import subprocess
import time

proc = subprocess.Popen('ls -lRa /', shell=True)
time.sleep(3)
proc.terminate()
proc.wait()

    Ici deux processus sont lancés: Popen engendre un sous-processus de l'exécution de l'interpréteur de commandes. La coquille à son tour engendre un sous-processus exécutant ls. proc.terminate() tue le shell, mais le processus secondaire de course ls reste. (Qui se manifeste par de copieux sortie, même après le script python a pris fin. Être prêt à tuer ls avec pkill ls.)

    • start_new_session=True ou de ses analogues permet de résiliation de l'ensemble du processus de l'arbre à la fois. Voir Comment mettre fin à un python sous-processus lancé avec shell=True
    • Je vous remercie de votre réponse m'a beaucoup aidé. P. S. proc = subprocess.Popen(['/run_python.py', '-n', '10'], shell=True) est différente de celle proc = subprocess.Popen("run_python.py -n 10", shell=True) Seul le dernier œuvres si la commande est construit au sommet d'un script python.
    • peut être un risque de sécurité si la commande provient de la saisie de l'utilisateur. Il est donc préférable d'utiliser shell=False si possible. Avec shell=False, l'approvisionnement de la commande et ses arguments dans une liste: proc = subprocess.Popen(['/run_python.py', '-n', '10'], shell=False).
    • donc proc = subprocess.Popen(['/run_python.py', '-n', '10'], shell=False) est-ce un processus de blocage? Je run_python.py exécuter à l'arrière-plan, qui peut durer de 1 heure.
    • est toujours non-bloquant. C'est l'appel de wait ou communicate qui bloque.
    • Mais si je n'utilise pas wait ma commande ne s'exécute jamais..?
    • Je ne vois pas ce comportement sur Windows 10 avec Python 3. Je suis en cours d'exécution à partir de VSCode intégré de la console. J'ai aussi essayé sur le terminal par défaut. Tous les processus enfants sont tués!
    • quel est le problème avec l'aide de subprocess.call([cmd,params,&])? c'est à dire l'ajout de la norme &?

    InformationsquelleAutor unutbu