13

MSDN says that

The maximum number of object handles is MAXIMUM_WAIT_OBJECTS

for WaitForMultipleObjects... On my computer that was defined as 64. Is it really only 64?

thanks

Wolf
  • 9,679
  • 7
  • 62
  • 108
Jake
  • 2,877
  • 8
  • 43
  • 62
  • Did you see something that gave you reason to doubt? If you think you need to wait on more than that many objects, consider asking a new question here detailing what you need to wait on and requesting suggestions on how to reduce your requirements. – Rob Kennedy Feb 27 '11 at 06:50
  • 3
    Actually, you can wait on more objects than that -- you just have to build a tree of events. It's documented on MSDN under "Remarks" ("To wait on more than MAXIMUM_WAIT_OBJECTS handles, use one of the following methods"): http://msdn.microsoft.com/en-us/library/ms687025(v=vs.85).aspx – Conrad Meyer Feb 27 '11 at 06:52

2 Answers2

20

Yes, it's really 64. Since it's a #define, it can't change without recompiling programs, so it pretty much can never change.

Since STATUS_ABANDONED_WAIT_63 is defined as 0xBF and STATUS_USER_APC is defined as 0xC0, if you incremented MAXIMUM_WAIT_OBJECTS by even just one, there would be no way to tell the difference between the 65th handle being abandoned and your wait being terminated by an APC. Properly changing MAXIMUM_WAIT_OBJECTS would require renumbering the status codes, which would require recompiling every Win32 program in existence.

Also, a program compiled with MAXIMUM_WAIT_OBJECTS defined as 65 would fail on an OS where it's defined as 64.

Gabe
  • 84,912
  • 12
  • 139
  • 238
  • 1
    That's of course not true. It could change today, and older programs would not need to be recompiled. Remember, it's a maximum. It's valid to wait on 3 objects when the maximum is 64, and it will be valid to wait on 64 objects when the maximum is increased to 128. – MSalters Feb 28 '11 at 11:47
  • 9
    @MSalters: You are, of course, wrong. If you took a program with 128 compiled into it and ran it on an OS with 64 compiled into it, the program would fail. – Gabe Feb 28 '11 at 13:05
  • 1
    I am, of course, right. That's what _WIN32_WINNT is for. You'd have the following in ``: `#if _WIN32_WINNT <= _WIN32_WINNT_WIN7 #define MAXIMUM_WAIT_OBJECTS 64 #else #define MAXIMUM_WAIT_OBJECTS 128`. Any program declared to run on older Windows versions would be bound by the older limit. Only programs that opt in to a new Windows version could benefit from the new API. – MSalters Feb 28 '11 at 15:09
  • 1
    @MSalters: Sorry, but what about all your 3rd-party DLLs? How do you make sure that all of your plug-ins, COM objects, and shell extensions have been recompiled? What if you try to use a recompiled COM object in a process where the main EXE wasn't recompiled? – Gabe Feb 28 '11 at 16:12
  • 1
    What about them? They all have to define `_WIN32_WINNT` but not necessarily to the same value. If they are built for `_WIN32_WINNT_WIN7` or lower, they get the 64 value, if higher they get the 128 value. It's really no different with new functions, there you also have to define a high-enough `_WIN32_WINNT`. Still, your Vista COM component can be loaded by your XP executable. – MSalters Mar 01 '11 at 07:54
  • 3
    @MSalters: You should read my answer. Increasing `MAXIMUM_WAIT_OBJECTS` by even 1 requires remapping the status codes, such that a process receiving new status codes would fail if it loaded a DLL expecting old status codes. – Gabe Mar 01 '11 at 12:30
  • Well, either remap that constant with the same conditional mechanism, or document that WaitForMultipleObjectsEx returns `WAIT_OBJECT_64 + n` for handles past the basic 64. I didn't say it would be a single-line change. – MSalters Mar 01 '11 at 12:48
  • 7
    @MSalters: I didn't say that it could never change; I said it could *pretty much* never change. Regardless, using `WAIT_OBJECT_64` as you suggest wouldn't work because that's changing the rules after the game has already started. MS can't just change documentation to say "If you define `_WIN32_WINNT` to be 0x0700 or higher you must carefully refactor any code that uses `MAXIMUM_WAIT_OBJECTS` to take `WAIT_OBJECT_64` into account" because people won't do it and their code will start to fail in strange and mysterious ways. – Gabe Mar 01 '11 at 13:10
  • i'm with @Gabe here - even tho STATUS_ABANDONED_WAIT_62 happens to be 190 and STATUS_ABANDONED_WAIT_63 happens to be 191 does not mean that STATUS_ABANDONED_WAIT_64 is required to be 192, as for legacy dlls and whatever, they should never use a count above 64 anyway... unless you have super shitty code that depends on WaitForMultipleObjects() returning an error value when you send count >64 at runtime, that's so edge-case shit that it shouldn't even be considered an issue. – hanshenrik Sep 14 '19 at 22:20
11

Yes, that's really the value of that macro.

Whether that's really the maximum number of objects that the function is capable of waiting on at once is an internal implementation detail. But if I were writing that function, I'd check the given array length to make sure it was within the documented bounds before proceeding, even if the rest of the code happened to be capable of waiting for more, because I wouldn't want consumers of the API to use more than the documented maximum and then come to rely on such undocumented behavior, thus placing requirements on any potential implementations of the function in future releases of the OS

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467