STINNER Victor <vstin...@redhat.com> added the comment:
> Victor or Steve, do you know the resolution of perf_counter() and monotonic()
> on Windows?
You can use:
>>> time.get_clock_info('perf_counter')
namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)',
monotonic=True, resolution=1e-09)
perf_counter() has usually a resolution much smaller than 1 ms (ex: 100 ns),
whereas monotonic() has a bad resolution (around 15.6 ms).
Rounding matters for the monotonic clock on Windows :-) Python should round
away from zero (ROUND_UP) for timeouts.
--
> I have found that using timeout with a python queue.Queue() results in an
> average delay of 14.5ms in Windows over Ubuntu in python 3.6.5/3.7, I
> subtracted the 1 ms timeout.
This behaviour looks correct to me. I suggest to close the issue.
Python rely on Windows API. Queue.get() uses a threading.Lock. On Windows,
lock.acquire(timeout=timeout) uses EnterNonRecursiveMutex() which expects a
number of a milliseconds. Even if you succeed to enhance the resolution of the
system clock, you will still be stuck to a resolution of 1 ms because of the
Windows API.
I'm not sure of what is your underlying question. Does it look inefficient to
you? You can use threads or asyncio to write more efficient code. But this is
out of the scope of the bug tracker :-)
I suggest to close this issue as "not a bug".
----------
_______________________________________
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
