Eryk Sun <eryk...@gmail.com> added the comment:
> 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.)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
