线程池的完成端口线程在异步I/O中的行为如何。NET/.NET核心

Question

的。NET/.NET Core线程池在内部使用两种不同类别的线程：工作线程和I/O完成端口（IOCP）线程。两者都只是通常的托管线程，但用于不同的目的。通过不同的API（例如任务。启动或线程池。QueueUserWorkItem）我可以在工作线程上启动CPU绑定的异步操作（不应该阻止，否则线程池可能会创建额外的工作线程）。

但是执行I/O绑定的异步操作呢？IOCP线程在这些情况下是如何工作的？具体而言，我有以下问题：

• 如果启动异步I/O操作（例如，对于文件、管道或网络），我怀疑当前线程调度异步请求。我还知道（通过“CLR via C#”一书），CLR注册到用于执行重叠异步I/O的I/O完成端口。我怀疑此IOCP绑定到异步操作，以便稍后可以将异步操作结果排队到线程池。因此，当异步请求启动时，没有触及IOCP线程的假设正确吗
• 我怀疑当异步I/O操作的结果通过CLR的I/O完成端口报告时，这就是IOCP线程的位置。结果将排队到线程池，并使用IOCP线程来处理它。然而，当阅读MSDN上的一些论坛线程时，我感觉IOCP线程实际上被用来发送请求，然后阻塞，直到返回结果。是这样吗？当I/O操作由对方系统处理时，IOCP线程是否阻塞
• 那么异步等待和同步上下文呢？IOCP线程是否处理异步I/O响应，然后（例如）在UI线程上排队继续（假设未调用ConfigureAwait（false）
• 那怎么办。Linux/MacOS X上的NET内核？没有I/O完成端口-是否以任何方式模拟它们

Answer 1

达米恩和汉斯在评论中为我指出了正确的方向，我想在这个回答中总结一下。

达米恩指出斯蒂芬·克利里的精彩博客文章回答了前三点：

• 异步I/O操作在调用线程上调度。没有涉及IOCP线程

Hans指出，Linux（epoll）和MacOS（kqueue）中有类似于IOCP的机制。