Note that the one type of timing test I couldn't apply this approach to are those that involve condition variables, since there's no way to account for oversleeping (i.e., longer than requested) in pthread_cond_timedwait. That is why the mac builds still use a slightly higher timeout. See this build output for an example.
Overall this makes the tests much more reliable on CircleCI. I think it will help other people making PRs so they don't wonder why the unit tests randomly fail in tests unrelated to their changes.
As discussed in https://github.com/boostorg/thread/pull/213#issuecomment-380600387
Note that the one type of timing test I couldn't apply this approach to are those that involve condition variables, since there's no way to account for oversleeping (i.e., longer than requested) in
pthread_cond_timedwait
. That is why the mac builds still use a slightly higher timeout. See this build output for an example.Overall this makes the tests much more reliable on CircleCI. I think it will help other people making PRs so they don't wonder why the unit tests randomly fail in tests unrelated to their changes.