Carlo Wood wrote:
On Mon, Sep 13, 2004 at 09:11:46PM -0700, Sean Kelly wrote:
Sort of. IOCP (completion ports) requires at least one thread to wait on a GetQueuedCompletionStatus call until data is ready to be processed. I typically do this with a worker thread or thread pool running in a fairly tight loop--data is consumed, broken into messages, and stuck in a synchronized queue for further processing by the main thread. But GetQueuedCompletionStatus does allow for a timeout parameter, so that worker thread could theoretically be the main thread. The only risk is that a server with a massive number of connections could possibly lose data if the worker thread spends too much time doing other things.
Can you explain in detail how it would be possible to lose data? I understood that when an IO operation finishes, then a 'IO completion packet' is send to the 'IO completion port' and queued there. If no thread is currently waiting in GetQueuedCompletionStatus then still nothing is lost: it will be queued until GetQueuedCompletionStatus is called again.
I was thinking of the socket recv buffer (SO_RCVBUF). Though I suppose this only holds true for UDP comms, so perhaps this isn't a big deal.
Sure, if the queue can run full and overflows ... then I guess we'd lose data - but that just means that the PC can't keep up with processing the IO using just one cpu. The user then should have the possibility to allow using more than one cpu (if he has them).
Agreed.
I find this a rather elegant solution for multi-processor computers. However, I don't have a multi-processor PC, so I am not insisting on using IOCP :p
Thig is, IOCP is really the only way to do high-end i/o multiplexing in Windows. I don't think the other options would scale well to thousands of connections.
Also, I now understand that this solution is *specifically* MT. It forces the user to write an MT application because his IO handling is handled in parallel by more than one thread. This cannot be done without that the user is aware of it. IOCP could be used in a way that only one thread is actually handling the IO (that is, calling the 'callback functions' of the user) but then using IOCP makes no sense.
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. Sean