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 eryksun
Recipients Gammaguy, eryksun, josh.r, paul.moore, rhettinger, steve.dower, terry.reedy, tim.golden, vstinner, xtreak, zach.ware
Date 2021-03-17.19:29:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1616009355.31.0.333334772861.issue34535@roundup.psfhosted.org>
In-reply-to
Content
> Given that extra info, I'd say we're fine to document that our timeouts 
> can't do any better than the OS, which "for example, is typically 
> around 15ms on Windows", and recommend using non-blocking calls 
> instead.

The 15.625 ms resolution limit is fine, as long as performance is predictable. I don't like the random inconsistency introduced by extending only certain waits, in different ways, to support SIGINT and/or waits longer than 49.7 days. For example, time.sleep() doesn't ignore WAIT_TIMEOUT to recompute the remaining time, so it's not subject to the resolution limit that's imposed by GetTickCount64().

I'd prefer a common implementation of _Py_Sleep, _Py_WaitForSingleObject, and _Py_WaitForMultiple objects in order to be able to definitively state that all wait timeouts are unconditionally limited to the resolution reported by time.get_clock_info('monotonic').resolution; are not limited to 49.7 days; and can be interrupted by Ctrl+C in the main thread -- except for waiting on I/O. (There's an open issue to enable Ctrl+C to cancel synchronous I/O in the main thread -- such as reading from a pipe.)
History
Date User Action Args
2021-03-17 19:29:15eryksunsetrecipients: + eryksun, rhettinger, terry.reedy, paul.moore, vstinner, tim.golden, zach.ware, steve.dower, josh.r, xtreak, Gammaguy
2021-03-17 19:29:15eryksunsetmessageid: <1616009355.31.0.333334772861.issue34535@roundup.psfhosted.org>
2021-03-17 19:29:15eryksunlinkissue34535 messages
2021-03-17 19:29:15eryksuncreate