Skip to content

Conversation

@JDevlieghere
Copy link

… (llvm#162197)

Compute the start time before registering the callback, rather than after, to avoid the possibility of a small race.

The following scenario illustrates the problem.

  1. The callback is registered with a 2 second timeout at t=0ms.
  2. We compute the start time after registering the callback. For the sake of argument, let's say it took 5ms to return from registering the callback and computing the current time. Start=5ms.
  3. The callback fires after exactly 2 seconds, or t=2000ms.
  4. We compute the difference between start and now. If it took less than 5ms to compute, then we end up with a difference that's less than 2000ms and the test fails. Let's say it took 3ms this time, then 2003ms-5ms=1998ms < 2000ms.

The actual values in the example above are arbitrary. All that matters is that it took longer to compute the start time than the end time. My theory is that this explains why this test is flaky when running under ASan in CI (which has unpredictable timing).

rdar://160956999
(cherry picked from commit 605e2d1)

…llvm#162197)

Compute the start time *before* registering the callback, rather than
after, to avoid the possibility of a small race.

The following scenario illustrates the problem.

1. The callback is registered with a 2 second timeout at t=0ms.
2. We compute the start time after registering the callback. For the
sake of argument, let's say it took 5ms to return from registering the
callback and computing the current time. Start=5ms.
3. The callback fires after exactly 2 seconds, or t=2000ms.
4. We compute the difference between start and now. If it took less than
5ms to compute, then we end up with a difference that's less than 2000ms
and the test fails. Let's say it took 3ms this time, then
2003ms-5ms=1998ms < 2000ms.

The actual values in the example above are arbitrary. All that matters
is that it took longer to compute the start time than the end time. My
theory is that this explains why this test is flaky when running under
ASan in CI (which has unpredictable timing).

rdar://160956999
(cherry picked from commit 605e2d1)
@JDevlieghere
Copy link
Author

@swift-ci test

@JDevlieghere
Copy link
Author

@swift-ci test macos

3 similar comments
@adrian-prantl
Copy link

@swift-ci test macos

@JDevlieghere
Copy link
Author

@swift-ci test macos

@JDevlieghere
Copy link
Author

@swift-ci test macos

@JDevlieghere JDevlieghere merged commit 011cb90 into stable/21.x Oct 9, 2025
3 checks passed
@JDevlieghere JDevlieghere deleted the cherrypick-605e2d1 branch October 9, 2025 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants