Issue 29472: subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/73658

classification

Title:	subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux
Type:	behavior	Stage:
Components:	Library (Lib)	Versions:	Python 3.6

process

Status:	open	Resolution:
Dependencies:		Superseder:
Assigned To:		Nosy List:	Griffon26, spoorcc
Priority:	normal	Keywords:

Created on 2017-02-07 11:57 by Griffon26, last changed 2022-04-11 14:58 by admin.

Files
File name	Uploaded	Description	Edit
test.py	Griffon26, 2017-02-07 11:58	A minimal example that shows the problem

Messages (1)
msg287230 - (view)	Author: Maurice van der Pot (Griffon26)	Date: 2017-02-07 11:57
This only happens when: - timeout is small enough - at least one stream is redirected to a PIPE When I know for certain that a subprocess has already terminated and I call communicate to retrieve its results with a timeout of 0 (or other small enough value), communicate will always return TimeoutExpired. The cause is that the check on timeout is done before the ready file descriptors are checked: https://hg.python.org/cpython/file/tip/Lib/subprocess.py#l1484. With a small enough timeout, communicate will never check the file descriptors for EOF. From a user perspective I would expect to be able to use communicate(timeout=0) to get the output for a process that I know has already terminated or to poll without blocking. Is this the intended behaviour of communicate or is it a bug? To me this behaviour is surprising.

msg287230 - (view)

Author: Maurice van der Pot (Griffon26)

Date: 2017-02-07 11:57

This only happens when:
- timeout is small enough
- at least one stream is redirected to a PIPE

When I know for certain that a subprocess has already terminated and I call communicate to retrieve its results with a timeout of 0 (or other small enough value), communicate will always return TimeoutExpired.

The cause is that the check on timeout is done before the ready file descriptors are checked: https://hg.python.org/cpython/file/tip/Lib/subprocess.py#l1484. With a small enough timeout, communicate will never check the file descriptors for EOF.

From a user perspective I would expect to be able to use communicate(timeout=0) to get the output for a process that I know has already terminated or to poll without blocking.

Is this the intended behaviour of communicate or is it a bug? To me this behaviour is surprising.

History
Date	User	Action	Args
2022-04-11 14:58:42	admin	set	github: 73658
2017-02-07 12:36:53	spoorcc	set	nosy: + spoorcc
2017-02-07 11:58:21	Griffon26	set	files: + test.py
2017-02-07 11:57:14	Griffon26	create