COM-функции порождают потоки, которые не исчезают

Question

Я работаю над небольшим приложением, которое предназначено для вызова некоторых (очень разнообразных) функций, которые, к сожалению, находятся вне моего контроля и разработаны таким образом, что я понятия не имею, пользователь действие сделан. В частности, некоторые из них порождают поток для выполнения своей работы, который в конечном итоге заканчивается в какой-то момент в будущем. Итак, некоторые из них реализованы в синхронизации, некоторые из них реализованы асинхронно, а мой код не знает, какой из них он будет.

только Цель моей заявки - запустить эти задачи и завершить работу по завершении. Поскольку цель - автоматизация, я ожидаю, что она будет вызвана в 100 раз из пакетных файлов в считанные минуты, поэтому я не хочу, чтобы процесс задерживался дольше, чем это было возможно.

Поскольку у меня нет никакого сигнала, я могу подождать, ExitThread() на моей основной теме, кажется, путь, так что любые потоки, порожденные внешним кодом, будут убивать процесс, когда они завершатся.

Итак, чтобы перейти к моей фактической проблеме, упомянутой в названии. :) Чтобы получить правильные интерфейсы для моего jig, мне нужно возиться с некоторыми функциями COM. SHParseDisplayName, IShellFolder::GetUIObjectOf и кучу других. Но уже после того, как я закончил с этими интерфейсами и выпустил их, эти потоки остаются присутствующими. Даже после того, как я позвонил CoUninitialize().

При проверке моего процесса с использованием Process Explorer большинство этих потоков, похоже, имеют ntdll.dll@EtwTraceMessageVa в качестве точки входа и застревают в ntdll.dll!ZwAlpcSendWaitReceivePort+0xa. Очевидно, что случайное завершение потоков с использованием TerminateThread здесь не является вариантом.

Как я могу заставить COM прекратить эти потоки, когда я закончил использовать его? Я использую W7 x64 для разработки.

Answer 1

Я выяснил проблему, и это был очевидный случай, когда вся документация была где-то, а не там, где вы смотрите, а у некоторой родственной темы был blog post по этой проблеме, которая привела меня к недостающему фрагменту.

Мое приложение всплывает IContextMenu файла (отсюда нет ShellExecute в моем коде), а затем позволяет вызвать команду. Однако некоторые глаголы, такие как properties, - это странные вещи, о которых я спрашивал: они порождают еще один поток и не дают никакого уведомления или очевидного способа его блокировки.

Использование SHSetExplorerInstance, как упоминалось в связанном посте, исправил мои проблемы. :)

Answer 2

Эти потоки не принадлежат COM. Они принадлежат к собственному пулу потоков Windows. Они предназначены для того, чтобы придерживаться, чтобы их можно было повторно использовать при необходимости. Предполагая, что нет ожидающих асинхронных обратных вызовов, вы должны иметь возможность отключить их. Пул потоков позаботится о том, чтобы быстро уничтожить потоки.