Является ли максимальное ограничение потока на самом деле неактуальной проблемой для Python/Linux?

1. «Из-за GIL одновременно выполняется один поток». Ну вроде. GIL означает, что только один поток может одновременно выполнять код Python. Однако любое количество потоков может выполнять ввод-вывод, различные другие системные вызовы или другой код, не содержащий GIL.

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

2. «Ядро Linux по умолчанию выделяет только 8 мегабайт для потоков». Я не уверен, где вы это услышали. Возможно, вы на самом деле слышали: «В Linux размер стека по умолчанию часто составляет 8 МБ», и это правда. Каждый поток будет использовать 8 МБ адресного пространства для стека (без проблем на 64-разрядной версии), а также ресурсы ядра для дополнительных карт памяти и самого процесса потока. Вы можете изменить размер стека с помощью библиотечной функции threading.stack_size, которая помогает, если у вас много потоков, которые не выполняют глубокие вызовы.

   >>> import threading
   >>> threading.stack_size()
   0 # platform default, probably 8 MiB
   >>> threading.stack_size(64*1024) # 64 KiB stack size for future threads
   

3. Другие в этом потоке предложили использовать асинхронную/неблокирующую структуру. Ну, ты можешь это сделать. Однако в современном ядре Linux многопоточная модель конкурирует с асинхронными (select/poll/epoll) методами мультиплексирования ввода-вывода. Переписать код для использования асинхронной модели — нетривиальный объем работы, поэтому я бы сделал это только в том случае, если бы не смог получить требуемую производительность от поточной модели. Если ваши потоки действительно пытаются имитировать человеческую задержку (например, проводят большую часть своего времени во сне), существует множество сценариев, в которых асинхронный подход на самом деле медленнее. Я не уверен, что это применимо к Python, где одно только уменьшение конкуренции GIL может заслуживать переключения.

Оба они частично верны:

• У каждого потока есть стек, и вы можете исчерпать адресное пространство для стека, если создадите достаточно потоков.

• В Python также есть что-то, называемое GIL, которое позволяет одновременно запускать только один поток Python. Однако, как только код Python вызывает код C, этот код C может выполняться во время выполнения другого потока Python. Однако потоки в Python по-прежнему являются физическими, и по-прежнему существует ограничение на размер стека.

Если вы планируете иметь много подключений, а не использовать много потоков, рассмотрите возможность использования асинхронного дизайна. Twisted, вероятно, подойдет здесь.