Commit b358b16
committed
Relax the assertion in
I just received the following recordings during local test execution:
```
Set([high(1), high(0)])
Set([high(1), high(0), high(2)])
Set([high(2), high(3), high(1), high(0)])
Set([high(2), high(3), high(1)])
Set([high(2), high(3)])
Set([high(2), high(3), high(4)])
Set([high(2), high(3), high(4), high(5)])
Set([high(3), high(4), high(5)])
Set([high(4), high(5)])
Set([high(4), high(5), high(6)])
Set([high(7), high(4), high(5), high(6)])
Set([high(7), high(5), high(6)])
Set([high(7), high(5)])
Set([high(5)])
Set([])
Set([low(0)])
Set([low(0), high(8)])
Set([low(0), high(8), low(1)])
Set([low(0), high(8), low(1), high(9)])
Set([low(0), high(8), low(1)])
Set([low(0), low(1)])
Set([low(1)])
Set([])
...
```
These recordings didn't satisfy the old assertion because a low-priority task started executing before the last high-priority task. But really what happened is that `low(0)`, `high(8)`, `low(1)`, and `high(9)` were all scheduled simultaneously and `low(0)` just happened to start executing a tiny bit before `high(8)`. To account for these races, relax the assertion to check that all high-priority tasks start executing before the first low-priority task finishes executing.testHighPriorityTasksGetExecutedBeforeLowPriorityTasks
1 parent 71dfc73 commit b358b16
1 file changed
+8
-3
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
39 | 39 | | |
40 | 40 | | |
41 | 41 | | |
42 | | - | |
43 | | - | |
44 | | - | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
| 48 | + | |
| 49 | + | |
45 | 50 | | |
46 | 51 | | |
47 | 52 | | |
| |||
0 commit comments