Handle transfer of config to subinterpreters

pep-0432.txt

@@ -60,10 +60,8 @@ environments).
 
 To keep the implementation complexity under control, this PEP does *not*
 propose wholesale changes to the way the interpreter state is accessed at
-runtime, nor does it propose changes to the way subinterpreters are
-created after the main interpreter has already been initialized (beyond
-any changes needed to make sure they continue working as expected). Changing
-the order in which the existing initialization steps occur in order to make
+runtime. Changing the order in which the existing initialization steps
+occur in order to make
 the startup sequence easier to maintain is already a substantial change, and
 attempting to make those other changes at the same time will make the
 change significantly more invasive and much harder to review. However, such
@@ -73,6 +71,7 @@ model and the configuration interface, so such changes should be easier
 once this PEP has been implemented.
 
 
+
 Background
 ==========
 
@@ -816,6 +815,38 @@ These are *snapshots* of the initial configuration settings. They are not
 modified by the interpreter during runtime (except as noted above).
 
 
+Creating and Configuring Subinterpreters
+----------------------------------------
+
+As the new configuration settings are stored in the interpreter state, they
+need to be initialised when a new subinterpreter is created. This turns out
+to be trickier than one might think due to ``PyThreadState_Swap(NULL);``
+(which is fortunately exercised by CPython's own embedding tests, allowing
+this problem to be detected during development).
+
+To provide a straightforward solution for this case, the PEP proposes to
+add a new API::
+
+    Py_InterpreterState *Py_InterpreterState_Main();
+
+This will be a counterpart to Py_InterpreterState_Head(), reporting the
+oldest currently existing interpreter rather than the newest. If
+``Py_NewInterpreter()`` is called from a thread with an existing thread
+state, then the interpreter configuration for that thread will be
+used when initialising the new subinterpreter. If there is no current
+thread state, the configuration from ``Py_InterpreterState_Main()``
+will be used.
+
+While the existing ``Py_InterpreterState_Head()`` API could be used instead,
+that reference changes as subinterpreters are created and destroyed, while
+``PyInterpreterState_Main()`` will always refer to the initial interpreter
+state created in ``Py_BeginInitialization()``.
+
+A new constraint is also added to the embedding API: attempting to delete
+the main interpreter while subinterpreters still exist will now be a fatal
+error.
+
+
 Stable ABI
 ----------