Re: [boost] Re: 2. It is unavoidable to use threads

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).

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