On Sat Jan 25 04:28:32 2025 +0000, Paul Gofman wrote:
The only thing... It doesn't seem like NtYieldExecution after server call doesn't make much sense? If we waited noone can ever tell whether we yielded or not. There could be in theory some difference for zero timeout, but it is server request anyway, it yielded enough while waiting for server reply. So I suggest to just remove the new return value from server_wait() and only care for yield and its status in NtYieldExecution()'s own yield with zero timeout (and always return 'yielded' result on alertable / server path). Then, the test looks actually inherently flaky, it is not given that it should ever yield in 50 attemps if the machine is not loaded, maybe worth not checking the conditions depending on that in 'if (0) and make a comment?
About flakiness: I could up the iteration count for yields (0 timeout waits) drastically without it increasing the total test time much. In practice, I've never seen this check fail on my fast machine under no load, and it's probably even less likely to fail on the comparatively sluggish test VM, but it wouldn't hurt.
About the yield after the server call: we only yield if we timed out, which I guess is what's supposed to emulate the "if it's hit by an event then it gets a priority boost" behavior, as "hit by an event" means the we didn't get `STATUS_TIMEOUT`. It's a bit backwards in that we're instead giving the other events a priority **penalty**, but I think that's the logic.