I / O完成端口的优点和缺点
为什么很多人说I / O完成端口是快速而好的模式？
什么是I / O完成端口的优点和缺点？
我想知道一些比其他模式更快的IOCP。
如果你可以解释一下比较其他模型（select，epoll，传统的multithreading/进程），那会更好。
I / O完成端口非常棒。 有没有更好的词来形容他们。 如果Windows中的任何事情都做对了，那就是完成端口。
你可以创build一些线程数（实际上并不重要），并将它们全部阻塞在一个完成端口上，直到一个事件（手动发布的，或者来自定时器或asynchronousI / O的事件，或者其他）到达。 然后完成端口将唤醒一个线程来处理事件，达到您指定的限制。 如果你没有指定任何东西，它会假设“最多CPU核心数”，这是非常好的。
如果已经有更多的活动线程超过最大限制，它将一直等到其中的一个完成，然后一旦进入等待状态就把事件交给线程。 而且，它总是会以LIFO顺序唤醒线程，因此caching仍然很温暖。
换句话说，完成端口是一个没有大惊小怪的“事件轮询”以及“尽可能多地填充CPU”的解决scheme。
您可以在完成端口，套接字或其他任何可以等待的地方抛出文件读写。 而且，如果您愿意，您可以发布自己的活动。 每个自定义事件至less有一个整数和一个指针值的数据（如果你使用默认的结构），但你并不仅限于此，因为系统也乐意接受任何其他结构。
另外，完成端口很快，真的很快。 曾几何时，我需要通知另一个线程。 实际上，这个线程已经有一个文件I / O的完成端口，但是它没有抽取消息。 所以，我想知道是否应该咬一口子，并使用完成端口简单，即使张贴线程消息显然会更有效。 我还没决定，所以我进行了基准testing。 令人惊讶的是，事实certificate，完成港口的速度大约快了3倍。 所以…更快更灵活，决定并不难。
通过使用IOCP，我们可以克服“一客一线”的问题。 众所周知，如果软件不能在真正的多处理器机器上运行，性能会大大降低。 线程是既不限制也不便宜的系统资源。
IOCP提供了一种方法来让less数（I / O工作者）线程处理多个客户端的“相当”的input/输出。 线程暂停，并且不要使用CPU周期，直到有事情要做。
你也可以阅读这本好书中的一些信息http://www.amazon.com/Windows-System-Programming-Johnson-Hart/dp/0321256190
根据我的经验，由于驱动程序中的错误，I / O完成端口的缺点可能是一些RS-232串行适配器的死亡蓝屏。
I / O完成端口由O / S作为asynchronousI / O操作提供，这意味着它出现在后台（通常在硬件中）。 系统不会浪费任何等待I / O完成的资源（例如线程）。 当I / O完成时，硬件向O / S发送一个中断，然后唤醒相关的进程/线程来处理结果。 错误：IOCP不需要硬件支持（见下面的注释）
通常情况下，单个线程可以等待大量的I / O完成，而在I / O尚未返回时占用非常less的资源。
其他不基于I / O完成端口的asynchronous模型通常使用线程池，并等待I / O完成，从而使用更多的系统资源。
另一方面，I / O完成端口通常需要硬件支持，所以它们通常不适用于所有的asynchronous场景。
