Привет, Хабр!

В C/C++ давно принято встраивать Python в приложения для скриптовой логики и плагинов. Именно эта экосистема много лет давала повод развивать в CPython идею нескольких изолированных интерпретаторов в одном процессе. Долгое время это было только в C‑API: создаёшь новый интерпретатор через Py_NewInterpreter, живёшь с одним общим GIL и кучей глобального состояния. В Python 3.12 появилось ключевое изменение — GIL стал на‑интерпретатор (каждый subinterpreter со своим GIL), но доступ был только через C‑API. В 3.14 подвезли полноценный высокоуровневый Python‑API: модуль concurrent.interpreters и InterpreterPoolExecutor.

Теперь можно писать параллельный код без multiprocessing, но с изоляцией уровня «почти процесс».

Дальше разберёмся, что это такое, когда это уместно вместо multiprocessing.

Что такое subinterpreters в Python

Это несколько изолированных интерпретаторов Python внутри одного процесса. У каждого свой импорт, свои модули, свой сборщик мусора и свой GIL. Независимые GIL дают честный мультикор при использовании нескольких потоков, каждый из которых переключается в свой интерпретатор. В 3.14 появился модуль concurrent.interpreters с удобными примитивами: создание интерпретаторов, запуск функций в них, безопасная очередь для обмена данными и готовый InterpreterPoolExecutor. Ограничения очевидны: между интерпретаторами нельзя свободно шарить произвольные объекты, большинство передаётся через pickle, а реально делятся»только небольшие классы объектов (например, memoryview) и сами очереди. Не все внешние модули из PyPI корректно изолированы — часть C‑расширений нуждается в доработке.

В чём выигрыш по сравнению с multiprocessing? Межинтерпретаторная очередь заметно быстрее, чем IPC между процессами; накладные на создание «воркера» обычно ниже, чем spawn процесса (особенно на платформах без fork). В замерах наблюдается 5–10× выигрыш на старте против spawn и кратное ускорение пересылки мелких сообщений. При этом, да, есть случаи, когда запуск тысячи интерпретаторов может оказаться не быстрее форка, зависит от шаблона.

Когда брать subinterpreters, а не multiprocessing

1. Когда бьёте большую CPU‑сборку задач на независимые под‑задачи, и хотите экономнее, чем процессы: меньше памяти, быстрый обмен через очередь, нет POSIX‑ограничений по количеству процессов.

2. Когда Windows — основной хост, а spawn мешает жить медленным стартом и необходимостью пиклить всё подряд. Здесь subinterpreters приятно экономят время старта и объём IPC.

3. Когда нужна изоляция окружения внутри одного процесса: разные версии библиотек, разные графы импортов, отсутствие случайного конфликта глобального состояния расширений. Для авторов C‑расширений есть отдельное how‑to —https://docs.python.org/3.14/howto/isolating‑extensions.html

4. Когда модель — CSP/actors: изолированные воркеры с message‑passing упрощают reasoning об ошибках и гонках без shared‑mutable.

Быстрый старт

InterpreterPoolExecutor даёт знакомый интерфейс concurrent.futures, но внутри использует пул интерпретаторов, а не процессы. Шапка if name == "__main__" обязательна, как и в multiprocessing, чтобы адекватно импортировать модуль в другом интерпретаторе.

# Python 3.14+
from concurrent.futures import as_completed, InterpreterPoolExecutor
import os

def cpu_task(n: int) -> int:
    # чистая математика без сторонних модулей — идеальный кандидат
    # никакого глобального состояния; аргументы и результат — pickle-friendly
    s = 0
    for i in range(1, n + 1):
        s += (i * i) ^ (i << 3)
    return s

if __name__ == "__main__":
    items = [50_000 + i * 10_000 for i in range(os.cpu_count() or 4)]
    results = []
    # подбирайте pool_size ~= числу ядер; пул лучше не пересоздавать
    with InterpreterPoolExecutor(max_workers=len(items)) as pool:
        futs = [pool.submit(cpu_task, n) for n in items]
        for f in as_completed(futs):
            results.append(f.result())
    print(sum(results))

В отличие от ProcessPoolExecutor, ничего не форкается, нет внешних процессов, а вычисления идут в нескольких потоках — каждый поток закреплён за своим интерпретатором с собственным GIL. В итоге пайтон масштабируется по ядрам без плясок со multiprocessing IPC. Фича официально в 3.14.

Здесь и дальше подразумеваем, что вы на 3.14+.

Обмен данными: Queue между интерпретаторами

Для message‑passing есть кросс‑интерпретаторная очередь с интерфейсом queue.Queue. Она быстрее межпроцессной очереди и позволяет посылать базовые типы, а также разделять буферы через memoryview.

from concurrent import interpreters
from threading import Thread

def worker_main(q_in_id: int, q_out_id: int) -> None:
    # Эта функция выполняется в другом интерпретаторе
    from concurrent import interpreters as _i
    q_in = _i.Queue(q_in_id)
    q_out = _i.Queue(q_out_id)
    total = 0
    while True:
        item = q_in.get()
        if item is None:
            break
        # item может быть int/bytes/str/tuple, а может быть memoryview
        if isinstance(item, memoryview):
            total += sum(item)  # доступ к общему буферу без копий
        else:
            total += int(item)
    q_out.put(total)

if __name__ == "__main__":
    q_in = interpreters.create_queue()
    q_out = interpreters.create_queue()

    interp = interpreters.create()
    interp.prepare_main({"q_in_id": q_in.id, "q_out_id": q_out.id})

    # Запускаем воркера в отдельном ОС-потоке, привязанном к другому интерпретатору
    t = interp.call_in_thread(worker_main, q_in.id, q_out.id)

    # Шлём данные: ints и memoryview поверх общего байтового буфера
    import array
    buf = array.array("B", bytes(range(128)))
    q_in.put(10)
    q_in.put(20)
    q_in.put(memoryview(buf))
    q_in.put(None)  # сигнал завершения

    t.join()
    print("sum =", q_out.get())

prepare_main привязывает объекты к main в целевом интерпретаторе. Очереди и memoryview допускают псевдо‑шаринг: это не копия через pickle, а обмен. В документации прямо перечисляют типы, которые копируются/шарятся, и ограничивает это списком. Если вы попытаетесь сунуть туда толстый объект, получите NotShareableError.

Держите протокол сообщений примитивным — числа, байты, кортежи из простых типов. Меньше неожиданностей, меньше скрытых затрат на сериализацию.

Работа с кодом: call, call_in_thread, exec, preloading

concurrent.interpreters поддерживает несколько сценариев запуска: синхронный call в текущем потоке с переключением контекста, call_in_thread с созданием нового потока, а также exec для исполнения строки кода. В проде я бы ограничился вызовом заранее импортированных функций и явным prepare_main.

from concurrent import interpreters

def heavy_import() -> None:
    # пример явной инициализации в целевом интерпретаторе
    import math  # локальный импорт, попадёт только туда

def run_job(x: int) -> int:
    import math
    return math.isqrt(x) ** 2

if __name__ == "__main__":
    interp = interpreters.create()
    # прогреваем окружение — импортируем что нужно в __main__ целевого интерпретатора
    interp.call(heavy_import)
    # теперь запускаем задачу
    res = interp.call(run_job, 123456789)
    print(res)
    interp.close()

Почему не exec с фрагментами? Потому что контроль сложнее, а рисков больше. Тем не менее, exec бывает полезен, например, для загрузки одного файла как модуля без загрязнения main. Если нужен запуск из файла, используйте runpy.run_path под капотом целевого интерпретатора.

Типичные проблемы и как их обходить

1. Не все C‑расширения безопасны в нескольких интерпретаторах. Модулям нужен per‑module state, без глобалей, и желательно heap‑types вместо статических типов. Есть подробный how‑to (ссылка выше). Если зависимость не готова, возможны крэши или странные эффекты при двойном импорте.

2. Передача объектов. По дефолту — pickle. Большие графы объектов тормозят. Планируйте протокол обмена. Когда нужно быстро, используйте memoryview и блочные байтовые буферы, а не списки из миллионов чисел.

3. Старт/останов. Создавайте интерпретаторы заранее и переиспользуйте. Эмпирика показывает, что многократный старт/стоп хуже пула; плюс запуск тысячами не самоцель и иногда проигрывает fork в микробенчмарках. Дёшево только в правильном режиме эксплуатации.

4. Guard в main. Всё так же обязателен. Нарушите — отстрелите себе ногу странными импорт‑эффектами и «не найденной» функцией в другом интерпретаторе.

Сравнение с multiprocessing

multiprocessing удобен, когда нужен процессный барьер: отдельное адресное пространство, чёткая граница по ресурсам, полноценные IPC и совместимость с миром POSIX. Но за это платим:

• Старт‑метод. На Linux часто быстро за счёт fork (copy‑on‑write). На macOS и Windows — spawn, это медленно и требует пиклить всё целиком. Существует forkserver как компромисс.

• IPC. Очереди и пайпы — это сериализация, контекстные переключения и ядро. Для мелких сообщений дорого. Есть shared_memory с ручным менеджментом, но это уже другой класс задач.

• Совместимость. Не пиклится — проблема. Плюс разные дефолты на разных платформах.

У subinterpreters обмен быстрее, старт дешевле, а код проще переносить между ОС, при этом изоляция на уровне интерпретатора закрывает большинство проблем с глобальным состоянием. Минусы — не все расширения готовы, есть ограничения на типы для обмена, а «безопасность как у процессов» это не про них: внутри одного процесса границы слабее.

Пул интерпретаторов + очереди

Скетч, который можно адаптировать под бэкенд обработки заданий — быстрый обмен, явная инициализация, корректное завершение.

from concurrent.futures import InterpreterPoolExecutor, wait, FIRST_EXCEPTION
from concurrent import interpreters
import os
import signal

def init_worker(env):
    # лёгкая инициализация под конкретное окружение интерпретатора
    import math
    globals().update(env)

def do_job(payload: bytes) -> bytes:
    # здесь полезная работа; аргументы и результат — байты
    # тяжёлые структуры — через memoryview/Queue
    return payload[::-1]

def runner(job_q_id: int, res_q_id: int, env: dict) -> None:
    from concurrent import interpreters as _i
    _i.get_current()  # просто чтобы явно подтянуть модуль
    init_worker(env)
    job_q = _i.Queue(job_q_id)
    res_q  = _i.Queue(res_q_id)
    while True:
        item = job_q.get()
        if item is None:
            break
        jid, payload = item
        res = do_job(payload)
        res_q.put((jid, res))

if __name__ == "__main__":
    job_q = interpreters.create_queue()
    res_q = interpreters.create_queue()

    # prewarm: отдельные интерпретаторы подготовит пул
    workers = os.cpu_count() or 4
    with InterpreterPoolExecutor(max_workers=workers) as pool:
        # поднимаем воркеров
        env = {"factor": 42}
        boots = [pool.submit(runner, job_q.id, res_q.id, env) for _ in range(workers)]

        # шлём задания
        for jid in range(100):
            job_q.put((jid, f"job-{jid}".encode()))

        # сигнал окончания каждому воркеру
        for _ in range(workers):
            job_q.put(None)

        # собираем результаты
        done = 0
        while done < 100:
            jid, data = res_q.get()
            # обработка результата...
            done += 1

        # ждём корректного выхода
        wait(boots, return_when=FIRST_EXCEPTION)

Здесь нет тяжёлого сериализатора поверх IPC, нет форков, нет зависимостей от внешних лимитов систем (типа ulimit по процессам), а протокол — строго байты/примитивы. Такой эскиз хорошо масштабируется по ядрам под CPU‑bound нагрузкой, если не лезть глубоко в расширения, которые не умеют жить в нескольких интерпретаторах.

Итог

Subinterpreters в 3.14 — это рабочая альтернатива multiprocessing для задач, где важны изоляция импортов, честный мультикор и быстрый обмен без межпроцессного IPC. Берём InterpreterPoolExecutor для знакомого интерфейса, используем create_queue и memoryview для дешёвого обмена, не надеемся на магию и проверяем сторонние C‑расширения на изоляцию. Если цель — скорость с контролируемой сложностью и без проблем spawn/fork, subinterpreters сейчас выглядят очень даже хорошим выбором.

Если после знакомства с продвинутыми возможностями Python, такими как subinterpreters, важно закрепить базовые навыки и построить прочный фундамент, стоит обратить внимание на курс Python Developer. Basic. Он охватывает ключевые элементы языка, работу с функциями, модулями и базовыми структурами данных.

Также для тех, кто хочет попробовать Python на практике, доступны бесплатные открытые уроки, где демонстрируются решения задач, подобных тем, что обсуждались в статье.

А если интересно, как другие участники осваивали Python с нуля, стоит ознакомиться с отзывами по курсу Python Developer. Basic. Это поможет увидеть, какие темы оказались понятными и полезными, и какие форматы занятий вызывают наибольший отклик.