gh-130363: add a test resource to mark tests that need an idle system

[rossburton]

Some tests are very sensitive to timing and will fail on a loaded system, typically because there are small windows for timeouts to trigger in.

Some of these are poorly implemented tests which can be improved, but others may genuinely have strict timing requirements.

Add a test resource so that these tests can be marked as such, and only ran when the system is known to be idle.

• Issue: Annotate test cases which are timing sensitive #130363

[vstinner]

Some tests are very sensitive to timing and will fail on a loaded system

Which tests? Do you have examples?

The Python test suite is reliable on busy / heavy loaded systems.

[rossburton]

The latest example which triggered this:

FAIL: test_timerfd_initval (test.test_os.TimerfdTests.test_timerfd_initval)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.13/test/test_os.py", line 4166, in test_timerfd_initval
    self.assertAlmostEqual(next_expiration, initial_expiration, places=self.CLOCK_RES_PLACES)
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 0.24403756000000001 != 0.25 within 3 places (0.0059624399999999855 difference)

The test is checking how accurately the timer is.

[vstinner]

Would be be possible to tune TimerfdTests to accept a large time difference, rather than skipping the test?

[rossburton]

Isn't the point of the test to check the timings though? Would it be considered a pass if the request was a 0.1 second timer and a bug meant it waited for 0.1 hours instead?

Found an existing bug for that specific test on another Linux system: #126112.

[mhsmith]

Found an existing bug for that specific test on another Linux system: #126112

These are two different timerfd tests. The one quoted above isn't really testing the timer at all – it never expires. It's really testing that a few lines of Python code can run within 1 millisecond. This has already been increased to 10 ms on Android emulators (see the comment at the top of the test class), and I think it wouldn't be unreasonable to extend that to all platforms.

By comparison, the test mentioned in #126112 has a much wider timing margin – 125 ms if I understand correctly – so either it's caused by something else, or my understanding is wrong.