因此，我一直在研究正在构建的服务器应用程序的套接字的重叠IO，并且不断看到有人说“永远不要使用hEvent”或“IO完成端口会更快”等，但从未有人说过为什么不使用hEvent，却没人能在完成端口上提供更快或更快的真实数据或编号。带有hEvent的WaitForMultipleObjects()更适合我的应用程序，因此，如果速度差异很小，我倾向于使用它，但是我不想在没有一些实际数据告诉我在此做出多大牺牲的情况下致力于这一点。 。我已经在Google，Google和Google上进行了搜索，除了一些StackOverflow回答说“不要使用此策略”而没有给出理由之外，找不到任何基准或文章，也无法对这两种策略进行比较。
有人能在这里为我提供一些有关hEvent和完成端口之间的实际差异的真实信息或数字吗？
最佳答案
该答案来自Harry Johnston，是对该问题的评论，经过一番搜索，我发现了一些其他细节，这些细节使WaitForMultipleObjects成为一件令人恐惧的事情。
您可以等待的最大对象数是64。这仅使WFMO方法的可伸缩性几乎不存在。但是进一步看，我发现了这个线程:https://groups.google.com/forum/#!topic/comp.os.ms-windows.programmer.win32/okwnsYetF6g
调度程序级别的自旋锁可以防止整个系统(即使具有多个内核)中的线程被抢占和分段。这很可怕，并且是一个很好的理由，如果您要等待3个以上的对象，则永远不要使用WFMO(该线程已预先分配了3个等待块，如果您等待3个或更少，则可以避免很多) 。
关于c++ - Windows:基于事件的重叠IO与IO完成端口，真实世界的性能，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/44664511/