Author eryksun
Recipients Leonardo Francalanci, docs@python, eryksun, martin.panter, paul.moore, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware
Date 2021-03-01.12:38:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1614602315.18.0.658589294541.issue31447@roundup.psfhosted.org>
In-reply-to
Content
I'm changing this to a documentation issue and removing the Windows component. The documentation doesn't make it clear that communicate() may block indefinitely (in both POSIX and Windows) even after the process has terminated. As currently implemented, this claim and the example need to be corrected. 

Depending on one's needs, the Popen() instance can be used as context manager to ensure that communication is finalized (e.g. in Windows, the synchronous reads in worker threads need to be canceled) and that the pipes are closed -- presuming you don't need to read more data after the timeout. If issue 43346 is resolved as suggested, then the following will work without blocking indefinitely in the second communicate() call:

    proc = subprocess.Popen(...)
    try:
        out, err = proc.communicate(timeout=15)
    except subprocess.TimeoutExpired:
        with proc:
            proc.kill()
        out, err = proc.communicate()
History
Date User Action Args
2021-03-01 12:38:35eryksunsetrecipients: + eryksun, paul.moore, vstinner, tim.golden, r.david.murray, docs@python, martin.panter, zach.ware, steve.dower, Leonardo Francalanci
2021-03-01 12:38:35eryksunsetmessageid: <1614602315.18.0.658589294541.issue31447@roundup.psfhosted.org>
2021-03-01 12:38:35eryksunlinkissue31447 messages
2021-03-01 12:38:35eryksuncreate