winapi - 根据 MSDN ReadFile() Win32 函数可能会错误地报告读取操作完成。什么时候？

Question

MSDN 在其对 ReadFile() 的描述中指出功能:

If hFile is opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must point to a valid and unique OVERLAPPED structure, otherwise the function can incorrectly report that the read operation is complete.

我有一些违反上述建议的应用程序，我想知道问题的严重性。我的意思是该程序使用由 FILE_FLAG_OVERLAPPED 创建的命名管道，但它使用以下调用从中读取:

ReadFile(handle, &buf, n, &n_read, NULL);

这意味着它通过了 NULL如 lpOverlapped范围。根据文档，该调用在某些情况下不应正常工作。我花了很多时间试图重现该问题，但我无法重现!我总是在正确的时间将所有数据放在正确的位置。不过，我只测试了命名管道。

有人知道我什么时候可以期望 ReadFile() 会错误地返回并报告成功完成，即使数据尚未在缓冲区中？为了重现问题，必须发生什么？文件、管道、套接字、控制台或其他设备会发生这种情况吗？我必须使用特定版本的操作系统吗？还是特定版本的读取(例如将句柄注册到 I/O 完成端口)？或者读写进程/线程的特定同步？

或者什么时候会失败？这个对我有用 :/

请帮忙!

对此，马丁

Answer 1

系统内部仅支持异步 I/O。对于同步 I/O，系统会创建一个临时 OVERLAPPED结构与 hEvent = NULL; ，发出一个传入这个临时的异步 I/O 请求，然后使用 GetOverlappedResult( bWait = TRUE ) 等待完成。 .

回想一下 hEvent临时OVERLAPPED结构是 NULL并注意GetOverlappedResult的备注部分:

If the hEvent member of the OVERLAPPED structure is NULL, the system uses the state of the hFile handle to signal when the operation has been completed.

一个文件 HANDLE是一个可等待对象，在 I/O 操作开始时变为无信号，并在 I/O 操作结束时发出信号。

现在考虑一个异步文件 HANDLE 的场景。在您发出同步 I/O 请求时有一个挂起的 I/O 请求。系统创建一个 OVERLAPPED结构并等待 hFile HANDLE为完成。与此同时，异步 I/O 完成，从而发出 HANDLE 信号。导致同步 I/O 在没有实际完成的情况下提前返回。

更糟糕的是，在响应同步 I/O 请求而启动的异步 I/O 完成时，它将更新临时 OVERLAPPED。不再存在的结构。结果是内存损坏。

完整的故事可以在 The Old New Thing 上找到。 .