How do Completion Port Threads of the Thread Pool behave during async I/O in .NET / .NET Core?

The .NET / .NET Core Thread Pool uses two different categories of threads internally: worker threads and I/O Completion Port (IOCP) threads. Both are just usual managed threads, but used for different purposes. Via different APIs (e.g. Task.Start or ThreadPool.QueueUserWorkItem) I can start CPU-bound async operations on the worker threads (which shouldn't block, otherwise the Thread Pool would probably create additional worker threads).

But what about performing I/O-bound asynchronous operations? How do the IOCP threads behave exactly in these situations? Specifically, I have the following questions:

• If I start an async I/O operation (e.g. for file, pipe, or network), I suspect that the current thread dispatches the async request. I also know (via the book "CLR via C#") that the CLR registers to an I/O completion port that is used to perform overlapped async I/O. I suspect that this IOCP is bound to the async operation so that it can queue the async operation result to the Thread Pool later. Thus, is my assumption correct that no IOCP thread is touched when an async request is started?
• I suspect that when the result of the async I/O operation is reported via the I/O completion port of the CLR, this is the place where IOCP threads come into place. The result is queued to the Thread Pool and an IOCP thread is used to handle it. However, when reading through some forum threads like this one on MSDN, I get the feeling that IOCP threads are actually used to dispatch the request and then block until the result is back. Is this the case? Are IOCP threads blocking while the I/O operation is handled by the opposing system?
• What about async await and SynchronizationContext? Does an IOCP thread handle the async I/O response and then e.g. queue the continuation on the UI thread (assuming that ConfigureAwait(false) is not called)?
• What about .NET Core on Linux / MacOS X? There are no I/O completion ports - are they emulated in any kind of way?

Damien and Hans pointed me into the right direction in the comments, which I want to sum up in this answer.

Damien pointed to Stephen Cleary's awesome blog post which answers the first three points:

• The async I/O operation is dispatched on the calling thread. No IOCP thread is involved.
• Consequently, no IOCP threads block during async I/O.
• When the result is returned to the .NET application, an IOCP thread is borrowed to mark the task complete. The continuation is queued to the target SynchronizationContext or the thread pool.

Hans pointed out that there are similar mechanisms to IOCP in Linux (epoll) and MacOS (kqueue).

UPDATE 2023-04-07: my original explanation of IOCP threads not blocking is wrong. When an IOCP thread is created, it is bound to an I/O Completion Port (on Windows) and then calls GetQueuedCompletionStatusEx in a loop. This call blocks until it is woken up because at least one new event is available on the IOCP. The IOCP thread makes its loop run to process all dequeued events (if you use the TPL, the corresponding task will be updated and the continuation will be queued, either on the caller's SynchronizationContext or on a Thread Pool worker thread). After that, the IOCP will call GetQueuedCompletionStatusEx and either block because no events are available, or the loop body can run again. This can be seen here: ThreadPoolPortable.IO.Windows.cs

While IOCP threads do block, the following statements are also true:

• No thread is created because an async method was called. The Thread Pool created and bound the IOCP threads beforehand, they probably have already been blocked before the async operation even started.
• The .NET Thread Pool will increase or decrease the number of IOCP threads depending on the async I/O workload that your app triggers.

UPDATE 2022-06-23: some people asked why IOCP threads do not block during I/O operations. It's important to understand how the Thread Pool manages its threads internally. The Thread Pool keeps a number of threads available, i.e. they reside in memory but are actually in a sleep state. This way when work comes in, you do not pay the cost of creating a new thread (my measurements on the topic show that creating a new thread instead of using an existing one is about 80 times slower). When work is available, it is queued to one of the sleeping threads, their state is changed from sleeping to ready to execute, and thus the operating system can pick this thread up in the next context switch (which usually occurs every 15ms) and assign it to one of your CPU cores. After your work is done, the thread is either put to sleep again or the next task can be executed on it. This is true for both worker threads and IOCP threads.

To conclude, IOCP threads do not block during the I/O operation, because only once the I/O completion port signals that the operation is complete, work is queued on an IOCP thread to mark the corresponding Task or Task<T> as completed and enqueue a possible continuation either on a worker thread or on the original caller thread if it has a synchronization context assigned to it and ConfigureAwait(false) was not called. During the I/O operation, the IOCP thread that will later execute the aforementioned work is either sleeping or handling completions from other I/O completion ports.