since this is similar to the main use you would get from asio, it is the fact that it is built on top of the IOF I / O ports (iocp short circuit). So, start by comparing iocp with WaitForMultipleObjects() . These two approaches are essentially the same as select vs. epoll on linux.
The main drawback of WaitForMultipleObjects , which was allowed by iocp, is the inability to scale with many file descriptors. This is O (n), because for each event you receive, you again go through the full array, and internally WaitForMultipleObjects must scan the array to know which descriptors to fire.
However, this is rarely a problem due to a second flaw. WaitForMultipleObjects() has a limit on the maximum number of handles it can wait on ( MAXIMUM_WAIT_OBJECTS ). This restriction is 64 objects (see Winnt.h). There are ways to get around this limitation by creating Event objects and associating multiple sockets with each event, and then wait for 64 events.
The third drawback is that WaitForMultipleObjects() actually has a subtle “error”. It returns the index of the handle that caused the event. This means that it can only transmit one event to the user. This is different from select , which returns all the file descriptors that triggered the event. WaitForMultipleObjects looks at the handlers processed in it and returns the first handle that has its own event.
This means that if you expect 10 very active sockets, all of which have some kind of event in them most of the time, there will be a very difficult bias in servicing the first socket in the list passed to WaitForMultipleObjects . This can be bypassed every time the function returns and the event is serviced, run it again with a timeout of 0, but this time only the part of array 1 will pass the event that was triggered. Repeatedly until all pens are visited, return to the original call with all pens and the actual timeout.
iocp solves all these problems, and also introduces an interface for more general event notification, which is pretty nice.
With iocp (and therefore asio):
- You do not repeat which pens you are interested in, you say windows once and remember this. This means that it scales much better with many handles.
- You have no limit on the number of pens you can wait
- You get every event, i.e. there is no bias to any particular descriptor
I'm not sure about your assumption to use async_read in a custom descriptor. You may need to check this out. If your handle refers to a socket, I would assume that it would work.
Regarding the issue of flow; Yes. If you run() io_service in multiple threads, events are sent to the free thread and will scale with a large number of threads. This is a feature of iocp that even has a thread pool API.
In short: I believe that asio or iocp will provide better performance than just using WaitForMultipleObjects , but regardless of whether this performance brings you, it mainly depends on how many pens you have and how active they are.