Как вернуть дескрипторы потоков, выделенные средой выполнения RPC?
Немного предыстории:
Я работаю над программой Windows, которая использует RPC для связи по сети. Сетевые подключения выполняются и отключаются непрерывно. Вызовы RPC являются синхронными, но одновременно работают более одного клиентского потока. Программы являются симметричными, то есть обе стороны действуют как клиент и сервер и используют одно и то же программное обеспечение. Это реализовано в C ++ с использованием стандартного Windows API.
Эта проблема:
Число дескрипторов потоков, о которых сообщает Process Explorer, со временем увеличивается. Похоже, что потоки создаются средой выполнения RPC для обработки запросов, но дескрипторы не всегда очищаются при освобождении потока.
Это число увеличивается, особенно когда передается много данных или когда одновременно происходит много вызовов (эти два фактора идут рука об руку, и я не уверен, что это актуально).
Активный сервер может создать несколько тысяч неиспользуемых дескрипторов потоков в течение нескольких дней, и при этом никогда не использовать более 20 потоков в любое время.
Вопрос:
Что я могу сделать, чтобы не увеличивать счетчик, потому что я считаю, что это может вызвать проблемы со стабильностью на сайтах клиентов?
Решение
Что удивительно, так это то, что даже когда поток завершается, он не освобождает все свои ресурсы. Вы должны позвонить CloseHandle() на ручке нити, которую вы получили от beginthreadex или как это называется. Кроме того, не (!!!) используйте CreateThread (), см. Документацию MSDN.
Есть еще одна вещь, которая, однако, не вызывает ваших проблем, это постоянный запуск и завершение потоков. Вместо этого используйте пул потоков. Кроме того, но это зависит от вашей фактической настройки, вам нужен только один поток на сетевой интерфейс для ввода-вывода и один поток на процессор для вычислений. Используя пул потоков, вы можете легко ограничить это число. Их контроль должен ограничивать накладные расходы, вызванные созданием / очисткой потока и переключением контекста. Это не всегда возможно, если соединение переключается между сетевым вводом-выводом, процессором и, возможно, дисковым вводом-выводом или даже пользовательским интерфейсом.
Другие решения
Других решений пока нет …