Зачем использовать ReadDirectoryChangesW асинхронно?
Я прочитал документацию для ReadDirectoryChangesW() а также видел CDirectoryChangeWatcher проект, но не говорите, почему кто-то хотел бы назвать его асинхронно. Я понимаю, что текущий поток не будет блокироваться, но, по крайней мере, для кода CDirectoryChangeWatcher, который использует порт завершения, когда он вызывает GetQueuedCompletionStatus(), этот поток блокируется в любом случае (если нет изменений).
Так что если я позвоню ReadDirectoryChangesW() синхронно в отдельном потоке, во-первых, мне все равно, если он блокирует, зачем мне вообще звонить ReadDirectoryChangesW() асинхронно?
3 ответа
Когда вы вызываете его асинхронно, вы получаете больше контроля над тем, какой поток ожидает. Это также позволяет вам в одном потоке ожидать нескольких вещей, таких как изменение каталога, событие и сообщение. Наконец, даже если вы выполняете ожидание в том же потоке, который изначально настраивал часы, это дает вам контроль над тем, как долго вы готовы ждать. GetQueuedCompletionStatus имеет параметр тайм-аута, который ReadDirectoryChangesW не предлагает сам по себе.
Я попытался использовать ReadDirectoryChanges в рабочем потоке синхронно, и думаю, что он заблокирован, так что поток не будет выходить сам по себе при выходе из программы. Поэтому, если вы не хотите использовать злые вещи, такие как TerminateThread, вам следует использовать асинхронные вызовы.
Вы бы вызвали ReadDirectoryChangesW так, чтобы он возвращал свои результаты асинхронно, если вам когда-нибудь нужно, чтобы вызывающий поток не блокировал. Тавтология, но правда.
Кандидаты на такие потоки: поток пользовательского интерфейса и любой поток, который несет единоличную ответственность за обслуживание ряда ресурсов (сокетов, любого вида IPC, независимых файлов и т. Д.).
Не будучи знакомым с проектом, я предполагаю, что CDirectoryChangeWatcher не заботится о том, блокирует ли его рабочий поток. Как правило, это характер рабочих потоков.