The scheduler test currently relies on exact timings, this is not workable in the busy Travis environment (or anything but a real-time operating system) resulting in random errors.
Ideally such a test would use mock times, but this is very invasive. For now, fix it by waiting until the number of tasks left to execute is zero before tearing down the threads.
The scheduler test currently relies on exact timings, this is not
workable in the busy Travis environment (or anything but a real-time
operating system) resulting in random errors.
Ideally such a test would use mock times, but this is very invasive.
For now, fix it by waiting until the number of tasks left to execute is
zero before tearing down the threads.
If there's a future bug that would otherwise cause this to fail because the tasks never successfully finish, this would now hang forever rather than failing, no? Maybe give it an absurd timeout, or verify that the numTasksInQueue are decreasing?
Hah! See #6146 for my fix, which should be more robust to the "what if a task never successfully finishes" case, is less straightforward, but I think is a better test.