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

From: Sean Kelly (sean_at_[hidden])
Date: 2004-09-15 15:46:20

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