PyO3/pyo3

Tracking Issue: Sub-Interpreter Support

Open

#3,451 opened on 2023年9月13日

GitHub で見る
 (29 comments) (15 reactions) (0 assignees)Rust (10,152 stars) (668 forks)batch import
Good First Issue

説明

Tracks the development and state of supporting sub-interpreters in PyO3.

This issue really only tracks progress, for discussing everything else, feel free to join over here: https://github.com/Aequitosh/pyo3/discussions/1

Summary

As of 13.09.2023

PyO3 currently doesn't support sub-interpreters, which will lead to an ImportError being raised if a module using PyO3 is initialized more than once per interpreter process. As stated in https://github.com/PyO3/pyo3/pull/2523, this is necessary in order to prevent soundness holes (as in, prevent things that use PyO3 from randomly breaking, having nasty undefined behaviour, etc.).

Even though this prevents soundness holes on the one hand, it can lead to modules / applications using a sub-interpreter model to "break" in certain situations. For examples, see https://github.com/pyca/cryptography/issues/9016 and https://github.com/bazaah/aur-ceph/issues/20.

Implementing sub-interpreter support isn't straightforward and requires quite a substantial redesign of PyO3's API. This issue shall track this redesign and provide as much relevant information as possible for all that wish to contribute.

Goals

Adapted from https://github.com/PyO3/pyo3/issues/576#issuecomment-1713975913, as of 13.09.2023.

Mid-Term

  • Rework synchronization primitives to not rely on the GIL. See https://github.com/PyO3/pyo3/pull/2885
    • Develop transition plan so that existing users can migrate their code without enormous amounts of work
    • Remove static data from PyO3's implementation, either move things to PyModule_GetState (preferred) or PyInterpreterState_GetDict (alternative)
  • Allow extension authors to use unsafe in order to opt in to sub-interpreter support - it is their responsibility to guarantee to not store Py<T> in any static data.
  • Document all conditions that extension authors' modules need to satisfy so that they may be used within sub-interpreters

Long-Term

Possibly remove the need for extension authors to audit their own code once we're confident enough.

Tasks

TBA - might them here (or some other place) once more concrete pieces of work have been identified.

Relevant Issues & Interesting Reads

Listing relevant things here. Some things might already be linked above, but it's nevertheless nice to have everything in one place.

コントリビューターガイド