[issue22043] Use a monotonic clock to compute timeouts

[STINNER Victor]

STINNER Victor added the comment:

pytimespec.patch removes *private* functions which were exposed in the stable ABI:

- _PyTime_gettimeofday()
- _PyTime_gettimeofday_info()

It also removes private macros:

- _PyTime_ADD_SECONDS()
- _PyTime_INTERVAL()

In pymonotonic.patch, I reused the same name but I didn't notice that they were part of the stable ABI. In pymonotonic-2.patch, I changed names so the dynamic loader will not load a module and the compiler will complain that symbols are missing.

Replaced/renamed functions:

- _PyTime_gettimeofday() => _PyTimeSpec_get_time()
- _PyTime_gettimeofday_info() => _PyTimeSpec_get_time_info()
- _PyTime_ADD_SECONDS() => _PyTimeSpec_add_sec()
- _PyTime_INTERVAL() => _PyTimeSpec_interval_sec()

I aslo added new functions:

- _PyTimeSpec_add_us()
- _PyTimeSpec_interval_us()

On overflow, _PyTimeSpec_add_sec() and _PyTimeSpec_add_us() sets the timestamp to the maximum value instead of returning an undefined value. I prefer functions over macros because I want to return an error on overflow (even if it's not used).

_PyTimeSpec_interval_us() also returns the maximum value in case of overflow.

_PyTimeSpec_interval_sec() should maybe take a mandatory round parameter instead of always rounding up.

I added _PyTime_unit_t for _threadmodule.c because acquire_timed() has a PY_TIMEOUT_T type which can be a long long. Maybe acquire_timed() can return an error if the timeout is too large, or loop? I would prefer to avoid this custom _PyTime_unit_t type.

I should maybe add unit tests for _PyTimeSpec_add_*() and _PyTimeSpec_interval_*() functions, as I did for _PyLong_FromTime_t(), _PyTime_ObjectToTimeval(), etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22043>
_______________________________________