为什么异步使用 ReadDirectoryChangesW？答案

【问题标题】：Why use ReadDirectoryChangesW asynchronously?为什么异步使用 ReadDirectoryChangesW？
【发布时间】：2009-07-14 17:21:49
【问题描述】：

我已经阅读了 ReadDirectoryChangesW() 的文档，也看到了 CDirectoryChangeWatcher project，但没有人说 为什么 不想异步调用它。我知道 current 线程不会阻塞，但是，至少对于使用完成端口的 CDirectoryChangeWatcher 代码，当它调用 GetQueuedCompletionStatus() 时，that 线程无论如何都会阻塞（如果没有变化）。

因此，如果我首先在一个单独的线程中同步调用ReadDirectoryChangesW()，而我不在乎它是否阻塞，我为什么还要异步调用ReadDirectoryChangesW()？

【问题讨论】：

标签： windows winapi readdirectorychangesw

【解决方案1】：

当您异步调用它时，您可以更好地控制哪个线程进行等待。它还允许您让单个线程等待多个事物，例如目录更改、事件和消息。最后，即使您在最初设置手表的同一线程中进行等待，它也可以让您控制愿意等待的时间。 GetQueuedCompletionStatus 有一个 ReadDirectoryChangesW 自身不提供的超时参数。

【讨论】：

【解决方案2】：

如果您需要调用线程不阻塞，您可以调用 ReadDirectoryChangesW 以异步返回结果。重言式，但事实。

此类线程的候选者：UI 线程和任何单独负责服务大量资源（套接字、任何类型的 IPC、独立文件等）的线程。

不熟悉该项目，我猜 CDirectoryChangeWatcher 并不关心它的工作线程是否阻塞。一般来说，这就是工作线程的本质。

【讨论】：

所以你说没有充分的理由？同样，正如我最初所说，如果我关心当前线程是否阻塞，我会创建一个单独的线程，我不在乎它是否阻塞。
创建线程并不总是一个（好的）选项，API 会尝试为尽可能多的用户提供服务，因此是异步选项。

【解决方案3】：

我尝试在工作线程中同步使用ReadDirectoryChanges，你猜怎么着，它被阻塞了，这样线程就不会在程序退出时自行退出。所以如果你不想使用 TerminateThread 之类的邪恶的东西，你应该使用异步调用。

【讨论】：

如果线程没有停止，那么你并没有真正告诉操作系统你的进程已经完成。 ExitProcess 终止所有线程。
来自 MSDN：“进程是如何终止的：进程一直执行，直到发生以下事件之一：-进程的任何线程调用 ExitProcess 函数。......不要终止进程，除非它的线程处于已知状态。如果线程正在等待内核对象，则在等待完成之前不会终止它。这可能会导致应用程序挂起。"
你可以从另一个线程调用CancelIoEx，这将结束RDC调用。但是，是的，这有点痛苦。使用同步 RDC，某些事件会因竞争条件而错过。