calling WaitForMultipleObject on more than 64 objects
Joe Burton
waiting for about 100 objects. The standard WIN32 call seems to top out at
64.
Has anyone ran into this problem? Can you point me in the right direction?
JBurton
jbbu...@ix.netcom.com
Gert Rijs
Hi,
This is a fixed limitation of WaitForMultipleObjects.
You can work around this by starting two threads and let thread A Wait on
the first 64 objects, and thread B on the other 36. Your main thread will
Wait for those 2 threads to finish.
hth,
gert
Joe Burton <jbbu...@ix.netcom.com> wrote in article
<6vhcf1$m...@dfw-ixnews5.ix.netcom.com>...
Gerd Sinne
>I have a need to call WaitForMultipleObjects, or something similar, while
>waiting for about 100 objects. The standard WIN32 call seems to top out at
>64.
>
>Has anyone ran into this problem? Can you point me in the right direction?
Yes, I know the problem. It is true that WaitForMultipleObjects only
supports 64 handles (I donn't know how its in NT5). I had to supervise
120 pipes in 2 way communications. I changed the whole reading/
writing/supervising mechanism to IOCompletionRoutines and it works
nice.
Also there might be a small speed improvment, cause the OS does not
always have to scan the full handles- array.
Another prob that you might avoid is the fact that the handles in the
lower part of the array , might be serviced more often than those in
the higher end. WaitForMultipleObjects doesn only return one handle
which is signaled, so either you check the other ones manually or you
rotate the array, so others also get a choice.
Hope it helps.
Regards
Gerd
wetboy
: I have a need to call WaitForMultipleObjects, or something similar, while
: waiting for about 100 objects. The standard WIN32 call seems to top out at
: 64.
What kinds of objects? Are they all, say, pipes or sockets on each of
which you're waiting for I/O completion?
-- Wetboy
Andrew Tucker
Check out Jason Clark's article _Waiting for More Than 64 Objects_
in the October 1997 issue of Windows Developer Journal.
HTH
Joe Burton (jbbu...@ix.netcom.com) wrote:
: I have a need to call WaitForMultipleObjects, or something similar, while
: waiting for about 100 objects. The standard WIN32 call seems to top out at
: 64.
:
: Has anyone ran into this problem? Can you point me in the right direction?
:
: JBurton
: jbbu...@ix.netcom.com
:
:
--
--
/* Andrew */
WWW: http://www.halcyon.com/ast
Email: a...@halcyon.com
Jamie Hanrahan
Organization: Kernel Mode Systems, San Diego, CA
Mime-Version: 1.0
Newsgroups: comp.os.ms-windows.programmer.win32
On Thu, 8 Oct 1998 08:17:51 GMT, g...@orga.com (Gerd Sinne) wrote:
>"Joe Burton" <jbbu...@ix.netcom.com> wrote:
>
>>I have a need to call WaitForMultipleObjects, or something similar, while
>>waiting for about 100 objects. The standard WIN32 call seems to top out at
>>64.
>>
>>Has anyone ran into this problem? Can you point me in the right direction?
>Yes, I know the problem. It is true that WaitForMultipleObjects only
>supports 64 handles (I donn't know how its in NT5). I had to supervise
>120 pipes in 2 way communications. I changed the whole reading/
>writing/supervising mechanism to IOCompletionRoutines and it works
>nice.
This is a the best solution.
>Also there might be a small speed improvment, cause the OS does not
>always have to scan the full handles- array.
NT doesn't EVER have to scan the handle array to figure out who gets
"unwaited" when a waitable object is signalled.
>
>Another prob that you might avoid is the fact that the handles in the
>lower part of the array , might be serviced more often than those in
>the higher end.
No.
>WaitForMultipleObjects doesn only return one handle
>which is signaled, so either you check the other ones manually or you
>rotate the array, so others also get a choice.
If none of the objects were signalled when you entered the wait, then
by definition, only one object is signalled when the wait is resolved,
so there is no need for it to have a mechanism to return more than one
handle!
It is true that other objects could become signalled later, but if you
"check the other ones manually" they could STILL become signalled
after you check... so you have to "go around the loop again" anyway,
so you might as well let your next wait pick up the next signalled
object, if any.
However, there IS an order-n-time cost associated with entering and
resolving a wait on _n_ objects. The limit of 64 is an arbitrary
limit chosen to keep you from doing silly things like waiting for
thousands of objects at once. Even at "only" 64 objects I would try
to limit the waits to no more than a few per second. I/O completion
ports really are a much better way to deal with many I/O devices at
once.
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA (j...@cmkrnl.com)
Drivers, internals, networks, applications, and training for VMS and Windows NT
NT kernel driver FAQ, links, and other information: http://www.cmkrnl.com/
Please reply in news, not via e-mail.