2 Open Questions

Should there be a subinterpreter "Serial Execution Mode"?

The idea is to introduce a mode in which using a subinterpreter is less perilous. This mode could be optional for subinterpreters (at the C level), though it's probably not worth it.

• disallow threading
• disallow forking
• eliminate the GIL within each subinterpreter
• start the subinterpreter in its own thread (and pin it there)
• (maybe) add mode management

What is the "main" thread of a subinterpreter?

...

Where does async fit in?

...

What to do about remaining C globals?

• freelists
• caches
• static types
• singletons
• interned objects
• _Py_IDENTIFIER
• ...

How to deal with tracking interpreters at a global level?

• store pointer
  • good: simpler, faster
  • bad: crash if interpreter already destroyed
  • requires a per-interpreter refcount
• store ID
  • good: safer
  • bad: failure when interpreter already destroyed happens at a distance from where interpreter recorded

What per-interpreter state should have a global counterpart?

options:

• keep global state (in PyRuntimeState) along with per-interpreter
• in special cases, treat the state of main interpreter as global

1. tracing

• as a global default

2. ? warnings

• it would have to be global (not main)
• what would global "warnings" config mean? default?

3. ? atexit

• set on main interpreter at C level (no objects owned by subinterpreters can be involved)

4. pending calls

• main interpreter already used for signal handlers
• "global" also means "any interpreter"? (not likely)

5. ? gc / allocators / etc.

• do we need global memory mgmt. for anything? (maybe)

6. ? GIL

• probably not; we'll use granular locks for cross-interpreter stuff

What per-interpreter state should be accessible from other interpreters?

1. pending calls

• e.g. for decref of shared objects

2. tracing?

• allow one interpreter to manage others

3. atexit?

• allow one interpreter to manage others

4. gc?

• allow one interpreter to manage others

What per-interpreter items need any further attention?

1. move pending calls to PyThreadState?
2. also support per-thread tracing?

How to ensure a signal handler runs in owning interpreter?

Signal handlers are triggered through the main interpreter. However, the registered functions should run in the interpreter where the function was created (i.e. the "owning" interpreter). This is due to the isolation requirements of subinterpreters when they do not share the GIL: objects cannot be used outside their owning interpreter.