In user space, there is a documented upper bound of 64 waitable objects in a
handle array. So I went to the DDK documentation, and it says if you give a
value > MAXIMUM_WAIT_OBJECTS that the system will terminate with a BugCheck
0x0C, MAXIMUM_WAIT_OBJECTS_EXCEEDED.
So a bit of groveling in the header files reveals
#define MAXIMUM_WAIT_OBJECTS 64
So if you need more than 64, you probably need a different solution.
(My own view: if you are doing a WaitForMultiple with a number of objects
which is not a compile-time-constant expression, You Are Doomed. The number
of times people code like this and forget to check for >
MAXIMUM_WAIT_OBJECTS is surprisingly high)
I would suggest some entirely different mechanism be considered, such as a
queue of completed requests and a simple KSEMAPHORE to indicate that there
is something in the queue.
Or, put another way, if you have 700 objects you are waiting for, you have
699 too many.
Note that KeWaitForMultipleObjects is subject to starvation; if objects of
some lower index are signaled frequently, objects of higher index, although
signaled, may never be seen, because the rule is that you get the index of
the lowest signaled object. I once had a client who had a CTC number of
handles (about 10, as I recall) do a “rotate” of the elements in the array
each time it came out of wait to guarantee antistarvation. But a queue is
cleaner.
The documentation is surprisingly bad, at least the old version I have
available today (I had a server meltdown last week and I’m waiting for the
new server parts to arrive, so the latest WDK on the server is
inaccessible). I says “If KeWaitForMultipleObjects returns STATUS_SUCCESS,
and if WaitAny is specified, KeWaitForMultipleObjects also returns the
zero-based index of the object that satisfied the wait at NTSTATUS”.
This makes neither grammatical sense nor functional sense.
If it returns STATUS_SUCCESS, the literal value 0, then it cannot return any
other value such as an index. I never heard of a function returning a value
“at” its return type. It might return a value “as” its return value.
If it were consistent with the user-mode documentation, it might say
"KeWaitForMultipleObjects can return one of the following values:
STATUS_SUCCESS through STATUS_SUCCESS + Count - 1: A value indicating
successful resumption due to one or more objects being signaled. In the
case of WaitAll, the value is always STATUS_SUCCESS. In the case of
WaitAny, the value is the index of the object that satisfied the wait. In
the case where multiple objects became signaled to satisfy a WaitAny, the
index of the lowest object is returned. WARNING! This can lead to
starvation of response to higher-numbered objects!
STATUS_USER_APC…
STATUS_TIMEOUT…
STATUS_ALERTED…"
Note that NT_SUCCESS will recognize this as successful completion, but it
also means you cannot distinguish the various NT_SUCCESS-compliant
completions (which include STATUS_ALERTED (0x101), STATUS_USER_APC (0xC0)
and STATUS_TIMEOUT (0x102) by a simple test that includes a test of the
literal value STATUS_SUCCESS, since this value will typically will not
happen in a KeWaitForMultipleObjects/WaitAny.
I’m also not sure why the OP said “a thread would not be necessary” because
a KeWaitFor implies that there is a thread waiting, and some other mechanism
(typically a DPC) is going to do something to terminate that wait. So
somewhere there is a blocked thread. And the implications of this blocked
thread need to be carefully considered.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 04, 2010 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KeSetEvent
The problem with it being so high is that you are consuming memory for no
reason
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.co.uk
Sent: Monday, January 04, 2010 9:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KeSetEvent
It could be made lower. It is only waiting for user approval on
applications.
Would there be a problem with it being so high?
Whoops - you’re using PKEVENTS, not KEVENTS.
My bad.
Still a whole lot of events, though.
mm
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.