COM-приложение, основанное на «свободной» модели потоков, подписывается на события, опубликованные в другом COM-приложении, для которого закончился процесс.
Приложение работает нормально. Но в некоторых случаях (или конфигурациях?) Он прожигает множество так называемых Tpp рабочих потоков.
Эти потоки, очевидно, принадлежат пулу потоков, управляемому Windows / COM. И они, по крайней мере, используются COM для доставки входящих событий в приложение.
Когда приложение получает события, это всегда происходит в контексте одного из этих рабочих потоков.
В обычном режиме В этой ситуации обновления поступают не более чем из 2 или 3 уникальных рабочих потоков.
Но в нештатной ситуации приложение видит новые уникальные идентификаторы рабочих потоков, которые появляются каждые 3-8 минут. За неделю приложение просмотрело около 1000 уникальных потоков (!).
Я очень подозреваю, что здесь что-то не так. Потому что, конечно, пулу потоков не нужно так много разных потоков, верно?
В чем может быть причина поведения пула потоков, которое я вижу. Это просто нормально, что время от времени создает разные потоки? Старые темы все еще не работают? Какое действие может вызвать это, когда приложение работает в контексте рабочего потока?
Примечания:
- Наше приложение является клиентом OP C DA (а другое приложение - сервером Siemens OP C -DA)
- ОС - это Windows 10
- Я пока не знаю, завершились ли рабочие потоки или они остаются бездействующими
В качестве эксперимента я попробовал несколько неудачных / недопустимые вещи, чтобы увидеть, возможно ли для нашего приложения каким-то образом разорвать рабочий поток - что тогда объяснило бы, почему пулу потоков пришлось бы создавать новый - мы могли бы уничтожить старый. Но это выглядит сложнее, чем я ожидал:
При работе в контексте рабочего потока я пытался ...
- сознательно зависать с
while (true) {}, результат: процесс доставки событий просто останавливается, новый рабочий поток для нас не создается, хотя - преднамеренное необработанное исключение c ++, новый рабочий поток не создается
- , инициирующее преднамеренное нарушение прав доступа (чтение), нет либо новый поток ...
И это заставило меня задуматься, если наше приложение не может уничтожить этот рабочий поток очевидным образом, что еще может или почему пул потоков будет вести себя так?