Jeremy Kloth <jeremy.kl...@gmail.com> added the comment:
> > 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 or >= INFINITE] 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 ---------- nosy: +jeremy.kloth _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46716> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
