CPU usage in polling message loop about xunit.stafact HOT 4 CLOSED

This is not waiting on handles, it waits on a 250ms timeout or a message arriving in the message queue. Its a standard pattern to wait for new messages arriving and the timeout guarantees your polling check is executed regularly (some other places chose 100ms timeouts, 250ms is the more common timeout in WinForms).

QS_ALLINPUT should be waiting on every possible kind of message even though the name hints to input its not just that, QS_INPUT would be the one waiting for input messages

from xunit.stafact.

Oh yikes, I might try to deny any memory of having written that code. Yuck.
Anyway, thanks for the tip on what handles I can sleep on to do better there.

from xunit.stafact.

I wonder though... those handles are user input centric, which don't apply at all in a unit test. You wouldn't want your unit test to hang just because there was no one there to move the mouse. I'm going to study why I'm in a DoEvents loop at all and see if there's a better option.

from xunit.stafact.

The alternative would probably be pushing an ApplicationContext frame similar to what you do in WPF, and then registering a callback to the task to terminate that frame.

(If you do that you have to be aware of your callstack and make sure the task completion callback isn't inlined when you do the call to request exit of the frame, we had lock inversion issues leading to deadlocks in tests when the caller was holding some other lock and tried to exit an application frame.)

from xunit.stafact.