Closed
Description
Bug report
Bug description:
$ ./python -m test test_time -m test_thread_time
Using random seed: 4026164953
0:00:00 load avg: 2.27 Run 1 test sequentially in a single process
0:00:00 load avg: 2.27 [1/1] test_time
test test_time failed -- Traceback (most recent call last):
File "/home/blue/cpython/Lib/test/test_time.py", line 535, in test_thread_time
self.assertLess(stop - start, 0.2)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
AssertionError: 0.26 not less than 0.2
test_time failed (1 failure)
== Tests result: FAILURE ==
1 test failed:
test_time
OS: NetBSD 10.0 amd64
CPython versions tested on:
CPython main branch
Operating systems tested on:
Other
Linked PRs
- gh-123978: Fix test_thread_time failure on NetBSD by adjusting threshold for time difference #123979
- gh-123978: Remove broken time.thread_time() on NetBSD #124116
- gh-123978: Remove support for thread_time and thread_time_ns in NetBSD #124196
- [3.13] gh-123978: Remove broken time.thread_time() on NetBSD (GH-124116) #124425
- [3.12] gh-123978: Remove broken time.thread_time() on NetBSD (GH-124116) #124427
Activity
furkanonder commentedon Sep 11, 2024
I have run the test many times, I get results between 0.10 and 0.30.
vstinner commentedon Sep 13, 2024
I suggest to skip test_thread_time() on NetBSD with a refererence to this issue.
serhiy-storchaka commentedon Sep 16, 2024
From the discussion on #123979, it seems that CLOCK_THREAD_CPUTIME_ID does not work as intended on NetBSD. The following example:
produces the following output:
It is expected
time.thread_time()
returning the result close totime.process_time()
on single-thread program, not close totime.time()
ortime.monotonic()
. The result includes the sleeping time, which should not be accounted.And this issue is known to the NetBSD developers: https://gnats.netbsd.org/57512.
We should either skip thread_time related tests on NetBSD and leave it to the users to deal with this issue, or remove the broken
time.thread_time()
on NetBSD. Not all clocks are supported on all platforms, so the latter should be more expected. Unfortunately we do not know when they fix this in NetBSD and how to detect that it is fixed (besides checking the OS version number which is still not known).There was similar issue on Solaris and Illumos (see #79636, https://www.illumos.org/issues/14126). Even if CLOCK_THREAD_CPUTIME_ID was provided in headers,
clock_gettime()
returned EINVAL. Unfortunately, there is nogethrvtime()
or other replacement on NetBSD.pythongh-123978: Remove broken time.thread_time() on NetBSD
serhiy-storchaka commentedon Sep 18, 2024
It puzzled me why
time.process_time()
is not broken in the same way. It uses thegetrusage(RUSAGE_SELF)
implementation. It turned out that while theclock_gettime(CLOCK_PROCESS_CPUTIME_ID)
implementation has higher priority, theclock_gettime(CLOCK_PROF)
implementation has even higher priority ifCLOCK_PROF
is defined.CLOCK_PROF
is defined on NetBSD, but not supported, soclock_gettime(CLOCK_PROF)
always fails and the code falls back togetrusage(RUSAGE_SELF)
. We are lucky that two errors cancel one other. But it is better to explicitly disable usingCLOCK_PROCESS_CPUTIME_ID
on NetBSD, until they fix it.There is also an error in conditions for the
clock_gettime(CLOCK_THREAD_CPUTIME_ID)
implementation:CLOCK_PROCESS_CPUTIME_ID
is used instead ofCLOCK_THREAD_CPUTIME_ID
. Although they are usually defined in pair, so this does not cause any practical issue.gh-123978: Remove broken time.thread_time() on NetBSD (GH-124116)
14 remaining items