Async I/O and I/O completion ports

re: Async I/O and I/O completion ports

Ricky Datta — Mon, 15 Dec 2003 13:59:00 GMT

Are you saying CLR does not use
CreateIoCompletionPort /PostQueuedCompletionStatus/... for asynch I/O on win2003 ?

re: Async I/O and I/O completion ports

kavita kamani — Mon, 15 Dec 2003 20:03:00 GMT

Yes the CLR thread pool threads (QueueUserWorkItem) do not use PostQueuedCompletionStatus. I think this excerpt clarifies that....

The full article is at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconThreadPooling.asp

There are several scenarios in which it is appropriate to create and manage your own threads instead of using the ThreadPool. You should do so:

.....
If you have a task that might run a long time (and therefore block other tasks).
.....

re: Async I/O and I/O completion ports

Feroze Daud — Sun, 25 Jan 2004 11:37:00 GMT

On all NT platforms, I/O completion ports are available for CLR applications to use. You can do this through the three functions in System.Threading.Thread:

1) Overlapped.Pack
2) Overlapped.Unpack
3) ThreadPool.BindHandle.

Normally, you dont need to call anyone of these functions, unless you are implementing a managed wrapper for a native NT object (eg: namedpipe). Some of the classes that ship in the framework (eg: Socket) automatically call these api's for you.

On NT, CLR threadpool will automatically start a CompletionPort thread, which calls GetQueuedCompletionStatus, and calls your I/o callback. So, for eg: System.Net.Sockets on NT automatically uses completion ports. So does System.IO.FileStream, and other native I/O related api's in the framework.

On 9x platforms, the System.Net.Sockets.Socket class defaults to Overlapped I/O.

re: Async I/O and I/O completion ports

Andy Neilson — Wed, 17 Mar 2004 17:26:00 GMT

I'm using the Overlapped.Pack, Overlapped.Unpack and ThreadPool.BindHandle methods to do async I/O on named pipes. This seems to work, but it seems that it should fail given what I know about the native APIs.

If I call BindIoCompletionCallback on a handle, the thread that initiates the I/O operation is not supposed to terminate before the I/O operation completes. This could be accomplished by queuing the operation that initiates the I/O to an I/O thread, thus ensuring that the calling thread never terminates before the I/O operation completes.

The problem is that ThreadPool.QueueUserWorkItem doesn't allow you to specify that the item should be processed on an I/O thread (as the native QueueUserWorkItem does).

Since this idiom is used by my code and the .NET Framework's async I/O implementation, and both seem to work, I have to assume that something is handling under the covers in the CLR that handles this properly. The lack of documentation or explanation makes me a bit nervous.

re: Async I/O and I/O completion ports

Kavita Kamani — Wed, 17 Mar 2004 22:28:00 GMT

Hi Andy,

You are perfectly right - there is some sort of support in C#, but there is no explicit way to say if an item should be delegated to an IO thread. Our team is talking with the CLR folks to get this support in the whidbey timeframe, but as of now, I dont have any status that I can disclose about this.
Kavita

re: Async I/O and I/O completion ports

Jamesy — Tue, 27 Apr 2004 17:17:00 GMT

I thought that Windows 9x systems could not support Overlapped I/O, as it required Winsock 2? is this correct?