COM-функции порождают потоки, которые не исчезают
Я работаю над небольшим приложением, которое предназначено для вызова некоторых (действительно разнообразных) функций, которые, к сожалению, находятся вне моего контроля и разработаны таким образом, что я понятия не имею, когда будет выполнено правильное действие пользователя. В частности, некоторые из них порождают нить для выполнения своей работы, которая в конечном итоге умирает в будущем. Так что некоторые реализованы синхронно, некоторые реализованы асинхронно, и мой код не знает, какой из них это будет.
Единственная цель моего приложения - запустить эти задачи и завершить их после завершения. Поскольку целью является автоматизация, я ожидаю, что ее вызовут сотни раз из пакетных файлов за несколько секунд, поэтому я не хочу, чтобы процесс затянулся дольше, чем это возможно.
Поскольку у меня нет сигнала, я могу ждать, ExitThread() в моем основном потоке, кажется, есть путь, так что любые потоки, порожденные сторонним кодом, в конечном итоге убьют процесс, когда они завершатся.
Так что теперь, чтобы перейти к моей актуальной проблеме, упомянутой в названии.:) Чтобы получить надлежащие интерфейсы для моего джига, мне нужно возиться с некоторыми функциями COM. SHParseDisplayName, IShellFolder::GetUIObjectOf и куча других. Но еще долго после того, как я закончил с этими интерфейсами и выпустил их, эти потоки остаются в наличии. Даже после того как я позвонил CoUninitialize(),
При проверке моего процесса с помощью Process Explorer, большинство из этих потоков, кажется, имеют ntdll.dll@EtwTraceMessageVa в качестве точки входа, и застряли в ntdll.dll!ZwAlpcSendWaitReceivePort+0xa, Очевидно, что случайное завершение потоков с помощью TerminateThread это не вариант здесь.
Как я могу получить COM для завершения этих потоков, когда я закончу с его использованием? Я использую W7 x64 для разработки.
2 ответа
Я выяснил проблему, и это был очевидный случай, когда вся документация была где-то, но не там, где вы ищете, и у некоторой связанной темы была запись в блоге по этой проблеме, которая привела меня к отсутствующей части.
Мое приложение выскакивает IContextMenu файла (следовательно, нет ShellExecute в моем коде), а затем позволяет вызвать команду. Тем не менее, некоторые глаголы, такие как properties это странности, о которых был мой вопрос: они порождают другую ветку и не дают никаких уведомлений или очевидных способов заблокировать их.
Использование SHSetExplorerInstance, как упомянуто в связанном посте, исправило мои проблемы.:)
Эти темы не принадлежат COM. Они принадлежат к пулу потоков Windows. Они предназначены для того, чтобы держаться, чтобы их можно было использовать повторно при необходимости. Предполагая, что нет ожидающих асинхронных обратных вызовов, вы должны быть в состоянии аккуратно завершить работу. Пул потоков позаботится о своевременном уничтожении потоков.