Den 3. nov. 2012 kl. 12:20 skrev Richard Oudkerk email@example.com:
On 03/11/2012 9:22am, Sturla Molden wrote:
No, it does something completely different. It registers a callback function for a single event object and waits. We were talking about multiplexing a wait for more than 64 objects.
By using an appropriate callback you easily implement something like WaitForMultipleObjects() which does not have the 64 handle limit (without having to explicitly start any threads).
But it uses a thread-pool that polls the registered wait objects, so the overhead (with respect to latency) will still be O(n). It does not matter if you ask Windows to allocate a thread-pool for the polling or if you do the polling yourself. It is still user-space threads that polls N objects with O(n) complexity. But if you nest WaitForMultipleObjects, you can get the latency down to O(log n).
IOCP is just an abstraction for a thread-pool and a FIFO. If you want to use a thread-pool and a FIFO to wait for something else than I/O there are easier ways. For example, you can use the queue functions in NT6 and enqueue whatever APC you want – or just use a list of threads and a queue in Python.