I’m on a pet peeve kick lately and another one of my big ones is WaitFor<Single | Multiple>Object with an INFINITE time out period.
You do realize it’s INFINITE right? And while you can mitigate the risk of actually spinning forever on an object, there’s really never 100% certainty that it will get signaled. As a co-worker pointed out, we SDETs should be and quite often are, fastidious and paranoid people and my paranoia rate increases when I see an INFINITE flag in test code.
Case in point;
retVal = WaitForMultipleObjects( HandleCount, Handles, FALSE, INFINITE);
Seems harmless enough right? You’ve got some in your own code, right? And if in testing you find this blurb hanging, the normal behavior is to fix where that handle is not being triggered, right?
Not so fast, in this particular case, the handles are events, and these events are packaged up and sent to a test driver which then signals the events (there’s a case condition which verifies the signaled event is actually the one we want).
All works well until you get a malicious tester like me who runs around and does something to intentionally block the driver from successfully loading. And BOOM goes your test, or in some cases your driver. This leads to emails from our lab engineers generally titled; <test> is hanging on <os | arch | build> in lab. And invariably, it’s because there’s a condition which wasn’t expected causing this stall.
So, change the timer!
retVal = WaitForMultipleObjects( HandleCount, Handles, FALSE, 120000);
I know what some of you are going to say, “but I can’t guarantee the operation will be completed in two minutes”. No you can’t, but somewhere between 0 and INFINITE – 1 it should be done, and if it isn’t, it’s a bug. Maybe not in your code, but in somebody’s code. I know there are corner conditions where INFINITE is a valid flag, and I’m fine with that, but I have a tough time believing there are that many. 🙂
*Currently playing – Dream Theater Status Seeker