views:

1342

answers:

1

We have a .NET application that makes several concurrent calls to various web services, collects their responses and then makes a few calculations off those responses. In attempting to derive additional performance, I've been investigating the use of approaches that make use of .NET's IO threading via the use of IO completion ports. I've read through several resources including Joe Duffy's recent book Concurrent Programming on Windows and while I "get" their usefulness, I'm a little unclear as to their behavior within .NET and am looking for a concise explanation.

+4  A: 

Chances are that you don't have to do anything if you are using the asynchronous methods already. Depending on the technology that you are using for the call to the web service, ultimately, it's going to drop down to the Win32 API to make the call to get bytes from the network, and to that end, it will use I/O Completion Ports in order to handle asynchronous calls.

The basic premise behind I/O completion ports is that when waiting on I/O operations, there is a thread pool that is kept waiting for when the I/O operations complete (assuming you registered to use I/O completion ports). When your registered operation completes, the thread from the I/O completion port thread pool is used to handle the callback.

Of course, after calling out to the I/O completion port, your thread can move on to do more work, or terminate, the choice is up to you.

The following should help describe it more:

I/O Completion Ports:

http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx

Inside I/O Completion Ports:

http://doc.sch130.nsc.ru/www.sysinternals.com/ntw2k/info/comport.shtml

casperOne
The bit about a shared pool doing work while the IO is off in IO land was exactly what I was hoping for. Thanks for the explanation.
James Alexander