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.

Author jeremy.kloth
Recipients eryksun, jeremy.kloth, jkloth, vstinner
Date 2022-02-13.16:42:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> > the fix should be as simple as coercing the timeout values to >= 0.
> Popen._remaining_time() should return max(endtime - _time(), 0).

That was my first initial instinct as well, however, that change would
also affect more of the Popen behavior and need a much more thorough
investigation of the POSIX side of Popen.

> Popen._wait() should raise OverflowError if the timeout is too large for the implementation. In Windows, the upper limit in milliseconds is `_winapi.INFINITE - 1` (about 49.7 days). It's important to only allow the timeout in milliseconds to be _winapi.INFINITE when `timeout is None`.

I agree.

> The DWORD converter in _winapi needs to subclass unsigned_long_converter. The current implementation based on the legacy format unit "k" is too lenient. Negative values and values that are too large should fail.

Whilst I agree this is a correct solution, I fear the potential
3rd-party breakage alone should bump this to its own issue.

I believe that this then leads to the following action items for this issue:
1) modify Windows Popen._wait() to raise on out of bounds values [< 0
2) cap Popen._remaining_time() return value to >= 0
3) change _winapi DWORD converter be unsigned long
4) use Job objects to group Windows processes for termination

Have I missed anything?  I should be able to knock out PRs for these today.
Jeremy Kloth
Date User Action Args
2022-02-13 16:42:30jeremy.klothsetrecipients: + jeremy.kloth, vstinner, jkloth, eryksun
2022-02-13 16:42:30jeremy.klothlinkissue46716 messages
2022-02-13 16:42:30jeremy.klothcreate