Why use ReadDirectoryChangesW asynchronously?

Question

I read the documentation for ReadDirectoryChangesW() and also saw the CDirectoryChangeWatcher project , but did not say why you should call it asynchronously. I understand that the current thread will not be blocked, but at least for the CDirectoryChangeWatcher code that uses the completion port when it calls GetQueuedCompletionStatus() , this thread blocks in any case (if there are no changes).

So, if I call ReadDirectoryChangesW() synchronously in a separate thread, first of all, I don’t care if it is blocked, why would I ever need to call ReadDirectoryChangesW() asynchronously?

Answer 1

When you call it asynchronously, you have more control over which thread is waiting. It also allows you to have one thread waiting for several things, such as a directory change, event, and message. Finally, even if you make a wait in the same thread that first sets the clock, it gives you control over how long you are ready to wait. GetQueuedCompletionStatus has a timeout parameter that ReadDirectoryChangesW does not offer on its own.

Answer 2

You would call ReadDirectoryChangesW in such a way that it returns its results asynchronously if you ever needed to prevent the calling thread from blocking. Tautology, but true.

Candidates for such streams are the user interface thread and any thread that is solely responsible for serving several resources (sockets, any IPC types, independent files, etc.).

Not familiar with the project, I think that CDirectoryChangeWatcher doesn't care if its workflow is blocking. This is typically the nature of workflows.

Answer 3

I tried using ReadDirectoryChanges in the workflow synchronously and guessing that it blocked so that the thread would not exit on its own when exiting the program. Therefore, if you do not want to use evil things like TerminateThread, you should use asynchronous calls.