On Wed, 15 Sep 2004, Carlo Wood wrote:
On Tue, Sep 14, 2004 at 07:56:49PM -0700, Sean Kelly wrote:
I disagree. IOCP makes sense any time the user expects the need to handle more than 31 simultaneous connections. Standard overlapped i/o may be fast but it doesn't scale as well as IOCP.
That would be a very interesting observation, but - what about IOCR (IO Completion Routines)? It seems to me that both have the same underlying mechanism and therefore I expect IOCR to scale equally well.
True enough. I couldn't remember the reason I opted not to use completion routines in the past--it may just have been that I didn't like the program flow that method required--so I decided to do some digging. I haven't verified this with other sources, but found an interesting quote here (http://www.certmag.com/bookshelf/c06615799.pdf): "Overlapped I/O with callbacks is not an option for several reasons. First, many of the Microsoft-specific extensions do not allow Asynchronous Procedure Calls (APCs) for completion notification. Second, due to the nature of how APCs are handled on Windows, it is possible for an application thread to starve. Once a thread goes into an alertable wait, all pending APCs are handled on a first in first out (FIFO) basis. Now consider the situation in which a server has a connection established and posts an overlapped WSARecv with a completion function. When there is data to receive, the completion routine fires and posts another overlapped WSARecv. Depending on timing conditions and how much work is performed within the APC, another completion function is queued (because there is more data to be read). This can cause the servers thread to starve as long as there is pending data on that socket." Still, completion routines do seem entirely reasonable, though the code will obviously require synchronization just like IOCP would. Sean