From: Sean Kelly (sean_at_[hidden])
Date: 2004-09-14 21:56:49
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).
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk