difference between asynchronous calls and asynchronous io calls in .net

Using a delegate I can call any function asynchronously. From the documentation I understand this is done by queueing a workitem for the threadpool.

One can also do asynchronous calls to IO开发者_StackOverflow functions (like reading from sockets, files, webpages, etc). I think (but I'm not sure) this does NOT spawn a workitem in the threadpool. Only after the result is obtained (or an error), is the callback called from a new thread in the threadpool.

Is this assumption correct? Or is an asynchronous IO call, also under the covers just some thread which is spawned? An if this is the case, how can asynchronous calls be any better performant than spawning threads (using a threadpool) yourself and block?

also: how many asynchronous calls can one have being dealt with at any given time? In case of a threadpool being used, I guess as much as you like. But in case of IO asynchronous calls, is there a limit? And is so, how do you know what the limit is?

Asynchronous IO is much more complicated thing than just using another thread from thread pool.

There are many different techniques inside OS, that support asynchronous IO:

1 Signaling a device kernel object

Not useful for performing multiple simultaneous I/O requests against a single device. Allows one thread to issue an I/O request and another thread to process it.

2 Signaling an event kernel object

Allows multiple simultaneous I/O requests against a single device. Allows one thread to issue an I/O request and another thread to process it.

3 Using alertable I/O

Allows multiple simultaneous I/O requests against a single device. The thread that issued an I/O request must also process it.

4 Using I/O completion ports

Allows multiple simultaneous I/O requests against a single device. Allows one thread to issue an I/O request and another thread to process it. This technique is highly scalable and has the most flexibility.