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

Question

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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