Boost logo

Boost :

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-13 18:20:10


Carlo Wood wrote:
> On Mon, Sep 13, 2004 at 03:27:12PM -0500, Aaron W. LaFramboise wrote:
>>2) IO completion routines.
>
> I asked my personal windows guru to give me an url about IO completion
> Ports and he told me:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/i_o_completion_ports.asp
>
> To my surprise, and possibly to your surprise as well ;), this starts as follows:
>
> <quote>
> I/O completion ports are the mechanism by which an application uses a pool
> of threads that was created when the application was started to process
> asynchronous I/O requests. These threads are created for the sole purpose
> of processing I/O requests.
> </quote>
>
> So... there we have our hidden threads!
> Did you know this?

Sorry, I've been overly loose with my terminology. I meant specifically
"I/O completion routines," which aren't the same thing as "I/O
completion ports." IOCR's are implemented using APCs, while IOCP's are
implemented using special support functions, which are not present on
Win 9x at all unfortunately.

I have not seen any benchmark comparison of IOCR's (and other
demultiplexing approaches) to IOCP's. I think I will put this on my
research TODO list.

I am advocating using IOCR's where possible in the general case. No
threads are required here.

I also think IOCP's could be useful, but only in specialized cases. In
particular, its my understanding that they are primarily useful in high
performance situations on high-end server hardware with at least two
CPU's. (I don't know if hyperthreading makes a difference here.) I
think this would be best implemented by a custom multiplexor extension,
perhaps through template mechanism as suggested by Jeff.

In any case, even with IOCP's, there should be no hiding the fact that
additional threads are being created, and the user should be given as
much control as possible in these specialized situations, as surely he
will need it then most.

Aaron W. LaFramboise


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk