Зачем использовать ReadDirectoryChangesW асинхронно?

Question

Я прочитал документацию для ReadDirectoryChangesW(), а также видел проект CDirectoryChangeWatcher , но ни один из них не сказал , почему можно было бы вызвать его асинхронно. Я понимаю, что поток current не будет блокироваться, но, по крайней мере, для кода CDirectoryChangeWatcher, который использует порт завершения, когда он вызывает GetQueuedCompletionStatus(), , который поток блокирует в любом случае (если есть без изменений).

Итак, если я вызываю ReadDirectoryChangesW() синхронно в отдельном потоке, в первую очередь, мне все равно, блокирует ли он, зачем мне вообще вызывать ReadDirectoryChangesW() асинхронно?

Answer 1

Когда вы вызываете его асинхронно, вы получаете больше контроля над , который поток ожидает. Он также позволяет одному потоку ожидать нескольких вещей, таких как изменение каталога, событие и сообщение. Наконец, даже если вы выполняете ожидание в том же потоке, который изначально настраивал часы, это дает вам контроль над тем, как долго вы готовы ждать. GetQueuedCompletionStatus имеет параметр времени ожидания, который ReadDirectoryChangesW не предлагает сам по себе.

Answer 2

Вы бы вызвали ReadDirectoryChangesW так, чтобы он возвращал свои результаты асинхронно, если вам когда-нибудь нужно, чтобы вызывающий поток не блокировал. Тавтология, но правда.

Кандидаты на такие потоки: поток пользовательского интерфейса и любой поток, который несет единоличную ответственность за обслуживание ряда ресурсов (сокетов, любого вида IPC, независимых файлов и т. Д.).

Не будучи знакомым с проектом, я предполагаю, что CDirectoryChangeWatcher не заботится о том, блокирует ли его рабочий поток. Как правило, это характер рабочих потоков.

Answer 3

Я попытался использовать ReadDirectoryChanges в рабочем потоке синхронно, и угадайте, что он заблокирован, чтобы поток не мог выйти сам при выходе из программы. Поэтому, если вы не хотите использовать злые вещи, такие как TerminateThread, вам следует использовать асинхронные вызовы.