> Question: under what circumstances will monotonic() exist but raise OSError?
On Windows, OSError is raised if QueryPerformanceFrequency fails.
Extract of Microsoft doc:
"If the function fails, the return value is zero. To get extended
error information, call GetLastError. For example, if the installed
hardware does not support a high-resolution performance counter, the
function fails."
On UNIX, OSError is raised if clock_gettime(CLOCK_MONOTONIC) fails.
Extract of clock_gettime() doc:
"ERRORS
EINVAL The clk_id specified is not supported on this system."
It may occur if the libc exposes CLOCK_MONOTONIC but the kernel
doesn't support it. I don't know if it can occur in practice.
>> - time.steady(): monotonic clock or the realtime clock, depending on
>> what is available on the platform (use monotonic in priority). may be
>> adjusted by NTP or the system administrator, may go backward.
>
> What makes this "steady", given that it can be adjusted and it can go
> backwards? Doesn't sound steady to me.
In practice, it will be monotonic in most cases. "steady" name is used
instead of "monotonic" because it may not be monotonic is other cases.
> Is steady() merely a convenience function to avoid the user having
> to write something like this?
steady() remembers if the last call to monotonic failed or not. The
real implementation is closer to something like:
def steady():
if not steady.has_monotonic:
return time.time()
try:
return time.monotonic()
except (AttributeError, OSError):
steady.has_monotonic = False
return time.time()
steady.has_monotonic = True
Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4