multiprocessing але сабінтерпретатори запускаються швидше ніж новий процес (але звісно повільніше ніж новий тред) і судячи з еспериментів Eric Snow мають менше накладних витрат.Доречі у 3.12 цю фічу вже можна помацати якщо імпортувати модуль
_xxsubinterpreters, але біжати писати продакшн код звісно не треба. Зараз виконувати у сабінтерпретаторі можна лише строки (ну тобто працює мийже як eval) і у 3.13 якраз мають доробити апі щоб можна було виконувати функції у окремому інтерпретаторі, а може додадуть й новий екзекутор до concurrent.futures. Взагалі схоже на те що сабінтерпретатори можуть розвиватись як горутини у Golang, бо shared пам'яті у них нема, а дані передавати можна будет через os.pipe, ну тобто напрошується якийсь механизм типу контекста.Щодо очевидних проблем їх реалізації. Якщо розробники зроблять апі якогось
SubInterpreterPool то їм треба буде очищати стейт сабінтерпретатора поміж викликами, бо якщо цього не робити, то те що буде виконуватись у окремому інтерпретаторі не буде детерміністичним, бо результат може залежати від порядку виконання функцій. Мене також турбує, як вирішать питання імпорту модулів. Тобто коли я хочу запустити функцію у сабінтерпретаторі, яка використовує імпортований модуль, як його автоматично імпортувати на старті? Я сподіваюся, що вони знайдуть розумне рішення, оскільки вимога робити імпорти прямо у функції була б зовсім не найкращим варіантом.Контекст:
- Python 3.12 Preview: Subinterpreters
- Python 3.12 Subinterpreters: A New Era of Concurrency