6

Since some people have different interpretation of the documentation, I'm trying to clarify once and for all the return value of WaitForMultipleObjects when

  1. bWaitAll = TRUE.
  2. all handles were signaled

Based on the documnation:
Return value
WAIT_OBJECT_0 to (WAIT_OBJECT_0 + nCount– 1)
If bWaitAll is TRUE, the return value indicates that the state of all specified objects is signaled.

Question

Say I have passed 5 handles to this function and all of them were signaled, is the return value WAIT_OBJECT_0?

Note

I'm trying to verify programmatically that WaitForMultipleObjects succeeded.

DWORD dwWaitForMultipleObjectsRes = WaitForMultipleObjects(dwOpenProcessCount, handles, TRUE, m_dwWaitTimeForProcToBeKilled);
if (dwWaitForMultipleObjectsRes != WAIT_OBJECT_0)
   // failed?

I want to verify the condition correctness.

Community
  • 1
  • 1
idanshmu
  • 5,061
  • 6
  • 46
  • 92
  • I wouldn't be surprised if the return value is NOT the first of all events, but either the latest signalled event or the last of all events. But I'm far from sure in this. It wouldn't be very hard to make something up that signals all events in forward, backwards and random order, and see what the result is (although it may of course vary between versions of the OS too!) – Mats Petersson Aug 24 '15 at 07:07
  • @MatsPetersson are you suggesting that the return value for such scenario may vary? if so, how will I know, problematically, that `WaitForMultipleObjects` succeeded? – idanshmu Aug 24 '15 at 07:14
  • If `bWaitAll` would be `FALSE` and all objects had signalled then the function had to return `WAIT_OBJECT_0` as it's the smallest value. So it's quite probable that `bWaitAll=TRUE` would yield the same result in practice. Yet the docs do not state it must do this way. So one shouldn't rely on it. – Matt Aug 24 '15 at 07:30

1 Answers1

6

The documentation is fairly clear that a return code from WAIT_OBJECT_0 through to WAIT_OBJECT_0 + nCount - 1 will be returned if the wait is satisfied:

If bWaitAll is TRUE, the return value indicates that the state of all specified objects is signaled.

It doesn't specify the exact value, so no one can say for sure what it will be other than it will be within that range.

So instead of testing if (dwWaitForMultipleObjectsRes == WAIT_OBJECT_0), you should test:

if ((dwWaitForMultipleObjectsRes >= WAIT_OBJECT_0)
&& (dwWaitForMultipleObjectsRes < (WAIT_OBJECT_0 + dwOpenProcessCount)))
{
    // wait satisfied, all objects signalled
}
Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Jonathan Potter
  • 36,172
  • 4
  • 64
  • 79
  • any feedback on @bkausbk comment? – idanshmu Aug 24 '15 at 07:53
  • @bkausbk: You can reverse engineer an implementation. You cannot reverse engineer a contract. Any given implementation can place additional restrictions, or relax others, that aren't part of the contract. What you believe to be a proof is nothing but a description, based on observations of one particular implementation. Considering that you believe, that a demo application can proof anything is quite revealing. – IInspectable Aug 24 '15 at 10:15