Negative run-time reported by subprocess.run's TimeoutExpired exception when setting timeout=0
#133089
Comments
…ut=None' when the timeout is zero Signed-off-by: Manjusaka <[email protected]>
|
Btw, even outside of unspecified behavior for import subprocess
subprocess.run(['echo', 'hi'], timeout = 1e-9)
# subprocess.TimeoutExpired: Command '['echo', 'hi']' timed out after -2.162200007660431e-05 secondsHow can time measurement be negative? Is it indicative of some other bug related to execution time measurement? |
|
if someone specifies an unrealistically small timeout such as 0 or 0.00001 they should expect to get a TimeoutError. timeout=0 should not disable the timeout. Requiring None for that is not a bug. It'd be reasonable to raise ValueError if the timeout supplied were < 0 but I would not consider that a bugfix. The tiny negative number in the error message in this case is due to timeout math being floating point, inexact, and fuzzy on posix it is calculated as an time delta of remaining time between steps and thus floating point precision can yield an odd looking result. the value in the error message is not the original timeout passed into the API call as that is not preserved and passed through into the self.wait(timeout=self._remaining_time(endtime)) call within |
I propose that semantics of this edge case is explained clearly in the docs. Because in different systems the semantics of For the negative number, of course I realize that it's most likely an artifact of some calculation, but it is again very surprising to see it as end user and there might be a suspicion of some bug somewhere. I propose that it's mentioned in the docs somewhere - or clipped up to zero to fix up the semantics (Allowing timeout=0 to have disabling semantics can simplify types to just being "float" instead of "float | None" in client user code, where the timeout value gets passed around many layers of indirection (including e.g. configs) |
|
I think the awkward error message is fixable, i left a note on the PR to see if they want to try doing that. |
…unc `subprocess.run` is called with a timeout (GH-133103) Signed-off-by: Manjusaka <[email protected]> Co-authored-by: Gregory P. Smith <[email protected]>
… the func `subprocess.run` is called with a timeout (pythonGH-133103) (cherry picked from commit 2bbcaed) Co-authored-by: Nadeshiko Manju <[email protected]> Signed-off-by: Manjusaka <[email protected]> Co-authored-by: Gregory P. Smith <[email protected]>
|
thanks for the report and contributions! |
…n the func `subprocess.run` is called with a timeout (GH-133103) (#133418) gh-133089: Use original timeout value for `TimeoutExpired` when the func `subprocess.run` is called with a timeout (GH-133103) (cherry picked from commit 2bbcaed) Signed-off-by: Manjusaka <[email protected]> Co-authored-by: Nadeshiko Manju <[email protected]> Co-authored-by: Gregory P. Smith <[email protected]>
|
I also thought about the floating-point computation being flaky but AFAIR, the timeout is computed using a monotonic clock so that's surprising. Or maybe the monotonic clock was not used in this specific case? |
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
This is quite unexpected that the measured run-time can be negative
In general, it's unclear in the docs what behavior should have
timeout=0. I would propose that it should disable timeout control, and should be equivalent totimeout=None.But in any case, negative run-times are quite strange :)
CPython versions tested on:
3.12
Operating systems tested on:
WSLv1+Ubuntu24.04
Linked PRs
TimeoutExpiredwhen the funcsubprocess.runis called with a timeout #133103TimeoutExpiredwhen the funcsubprocess.runis called with a timeout (GH-133103) #133418The text was updated successfully, but these errors were encountered: