Python-сообщество

Всем привет. Есть скрипт работающий с сетью в несколько процессов (multiprocessing.Process). Каждый из процессов поднимает внутри себя несколько сотен потоков (threading.Thread). Пропорционально качеству сети, потоки время от времени кидают эксепшены о проблемах чтения из сокетов. Уменьшение количества потоков сводит к нулю такие ИС. При возникновении ИС потоки не умирают, а просто возвращают задачу в очередь и берут следующую в работу.

Вопрос вот в чём. Есть ли какой-то алгоритм или паттерн описывающий в подобных ситуациях регуляцию кол-ва потоков в зависимости от частоты возникновения ИС отдельного типа?

Хочу получить примерное следующее - если в течение времени T на Х запросов у нас возникает N ошибок, то каждому процессу даётся команда убить у себя по 10 потоков. Ожидаем T. И так пока за время T не будет ошибок вовсе.
Главная проблема в вышеописанной схеме - как именно без ущерба для работы убивать потоки? Они ведь в момент терминейта будут работать с какой-то конкретной задачей.

Пока что пришло в голову только создание у потоков св-ва типа need_die и постоянной его проверки. Если оно True, то поток завершает работу и помирает. А св-во это будет проставлять процесс, рандомным образом выбирая из пула N потоков.

Отредактировано WhiteTiger (Дек. 23, 2016 14:47:03)

WhiteTiger
Есть скрипт работающий с сетью в несколько процессов (multiprocessing.Process). Каждый из процессов поднимает внутри себя несколько сотен потоков (threading.Thread).

Как-то это всё странновато звучит. Лучше код скинь.

К сожалению код опубликовать не могу из-за policy. Общая схема такова - с помощью multiprocessing.Process создаётся 4 процесса (=cpu cores) с вызовом функции генерирующей (к примеру) 200 потоков. Итоговые 800 потоков работают с сетью получая данные из очереди multiprocessing.Queue. Если пускать скрипт через WiFi, то при тех же 800 итоговых потоков часто возникает ошибка чтения из сокета внутри них. Если при запуске интернет подключен по кабелю, то кол-во потоков можно ещё увеличивать и увеличивать.
Вопрос вырос из того что нет каких-то конкретных условий запуска скрипта в плане качества сети. Сегодня его пустят с ноута, завтра с сервера с хорошим каналом и заставлять конечного юзера подбирать оптимальное кол-во потоков не хочется. Поэтому решил сваять какой-нибудь механизм саморегуляции, чтоб в течение первых минут 10 работы скрипт сам убил лишние потоки и далее стабильно работал.