什么时候IO完成端口包发送，什么时候没有？

我目前正在使用IO完成端口基于命名pipe道的IPC机制。

不幸的是，我有一些msdn文档的麻烦，因为我不清楚在哪些情况下调用ReadFile / WriteFile结果完成数据包。

ERROR_IO_PENDING返回FALSE的情况很明显，但是在返回ERROR_MORE_DATA时显然可能出现这种情况呢？ 在这种情况下会有一个完成包吗？ 而且，如果还有其他错误呢？ 在哪些情况下，我必须直接处理结果和释放资源，而不是在完成处理程序中？

另一种情况是如果ReadFile / WriteFile甚至成功，这显然也是可能的。 MSDN 在这里感谢很清楚：

窗口HTTP IO完成端口

WriteFile与IO完成端口问题

在串口实际closures之前，CloseHandle（）会返回

套接字服务器的高效重叠I / O

在没有ConnectEx的情况下，Windows上的非阻塞套接字连接

此外，即使WriteFile函数使用asynchronous句柄（也可以返回FALSE和ERROR_IO_PENDING），WriteFile函数有时会返回TRUE，并且返回ERROR_SUCCESS的GetLastError值。 …在这个例子中，build议将允许完成端口例程全部负责这些资源的所有释放操作。

这个build议在所有情况下都是正确的，并且分配给完成端口的句柄的ReadFile / WriteFile操作的结果可能（而且应该）实际上被完全忽略，因为无论如何都将数据包发送到端口。

iocpreactor发布状态扭曲

资源在Windows上学习IOCP

只要IO操作能够启动，IO操作就会排队等待IO操作。 无论IO操作开始后是否遇到错误，完成项目都将排队到完成端口。

IO系统返回的NTSTATUS代码与Win32错误代码之间存在映射问题，这使得很难判断哪些状态是错误的，哪些只是信息性的。 内核和本地API使用的NTSTATUS有四个严重级别：成功，信息，警告和错误。 除了错误代码之外的任何内容都会表示IO操作能够启动。 Win32只有一个严重程度（ ERROR_* ），所以成功，信息和警告代码必须与错误代码一起映射。

ERROR_IO_PENDING – STATUS_PENDING是成功状态

ERROR_MORE_DATA – STATUS_BUFFER_OVERFLOW警告或STATUS_MORE_ENTRIES成功状态

您可以忽略ReadFile或WriteFile返回的任何非错误代码，并期望排队完成项目，但是确定哪一个可能有点痛苦。 这将是很好，如果Win32错误代码组织得更好，但微软确实提供从NTSTATUS到Win32错误代码的映射： http : //support.microsoft.com/kb/113996 。 请参阅平台SDK或VS安装中的ntstatus.h ，以确定NTSTATUS代码的严重程度。

原始API调用返回时，IO操作可能会完成，例如刚刚从缓存中复制出来的读请求（不需要异步等待）。 为了保持一致性，完成消息仍将排队等待。

是的， ERROR_MORE_DATA完全可能出现在完成数据包中。 你应该随时准备处理任何潜在的错误。 在GetQueuedCompletionStatus的文档中很清楚，当它返回FALSE ，你应该检查lpOverlapped参数是否为NULL 。 如果不是NULL ，则I / O完成数据包包含错误。

即使ReadFile或WriteFile返回TRUE完成数据包也会排队到完成端口。 从Windows Vista开始，可以更改此策略。 请参阅SetFileCompletionNotificationModes上的文档。