記憶體分配器

這是隔離直譯器工作中最敏感的部分之一。最簡單的解決方案是將內部“小塊”分配器的全域性狀態移至 PyInterpreterState，就像我們處理幾乎所有其他執行時狀態一樣。以下將詳細闡述其細節和原理。

CPython 提供了一個記憶體管理 C-API，具有三個分配器域：“raw”、“mem”和“object”。每個域都提供等效於 malloc()、calloc()、realloc() 和 free() 的功能。可以在執行時初始化期間設定每個域的自定義分配器，並且可以使用相同的 API 包裝當前分配器以新增鉤子（例如，標準庫的 tracemalloc 模組）。分配器目前是執行時全域性的，由所有直譯器共享。

“raw”分配器預期是執行緒安全的，預設使用 glibc 的分配器（malloc() 等）。然而，“mem”和“object”分配器預期不是執行緒安全的，目前可能依賴 GIL 來保證執行緒安全。這部分是因為兩者的預設分配器，即“pyobject”，不是執行緒安全的。這是因為該分配器的所有狀態都儲存在 C 全域性變數中。（參見 Objects/obmalloc.c。）

因此，我們又回到了隔離執行時狀態的問題。為了讓直譯器停止共享 GIL，必須解決分配器的執行緒安全問題。如果直譯器繼續共享分配器，那麼我們需要其他方法來獲得執行緒安全。否則，直譯器必須停止共享分配器。在這兩種情況下，都有許多可能的解決方案，每種方案都有潛在的缺點。

為了保持分配器共享，最簡單的解決方案是在 PyMem_Malloc()、PyObject_Malloc() 等函式中對“mem”和“object”分配器呼叫使用細粒度的執行時全域性鎖。這將影響效能，但有一些方法可以緩解（例如，只有在建立第一個子直譯器後才開始加鎖）。

另一種保持分配器共享的方法是要求“mem”和“object”分配器是執行緒安全的。這意味著我們必須使 pyobject 分配器的實現執行緒安全。這甚至可能涉及使用可擴充套件分配器（如 mimalloc）重新實現它。潛在的缺點是重新實現分配器的成本以及此類工作固有的缺陷風險。

無論如何，轉向要求執行緒安全的分配器將影響所有嵌入 CPython 且當前設定了非執行緒安全分配器的人。我們需要考慮誰可能受到影響以及如何減少任何負面影響（例如，新增一個基本的 C-API 來幫助使分配器執行緒安全）。

如果我們確實停止了在直譯器之間共享分配器，那麼我們必須只對“mem”和“object”分配器這樣做。我們可能還需要保留一組完整的全域性分配器用於某些執行時級別的使用。由於查詢當前直譯器然後透過指標間接獲取分配器，這將帶來一些效能損失。嵌入者也可能需要為每個直譯器提供一個新的分配器上下文。從好的方面看，分配器鉤子（例如 tracemalloc）不會受到影響。

最終，我們將選擇最簡單的方案：

• 將分配器保留在全域性執行時狀態中
• 要求它們是執行緒安全的
• 將預設物件分配器（又稱“小塊”分配器）的狀態移至 PyInterpreterState

我們嘗試了一個粗略的實現，發現它相當簡單，而且效能損失基本為零。

PyInterpreterConfig.own_gil

如果為 true (1)，則新直譯器將擁有自己的“全域性”直譯器鎖。這意味著新直譯器可以在不被其他直譯器中斷的情況下執行。這有效地解除了多核的全部使用障礙。這是本 PEP 的根本目標。

如果為 false (0)，則新直譯器將使用主直譯器的鎖。這是 CPython 中遺留的（3.12 之前的）行為，所有直譯器共享一個 GIL。當使用仍然依賴 GIL 進行執行緒安全的擴充套件模組時，這樣共享 GIL 可能是可取的。

在 PyInterpreterConfig_INIT 中，這會是 true。在 PyInterpreterConfig_LEGACY_INIT 中，這會是 false。

另外，為了安全起見，目前我們不允許在執行時初始化期間設定了自定義分配器的情況下將 own_gil 設定為 true。包裝分配器（例如 tracemalloc）仍然可以正常工作。

PyInterpreterConfig.strict_extensions_compat

PyInterpreterConfig.strict_extension_compat 基本上是用於“PyInterpreterState.strict_extension_compat”的初始值。

擴充套件模組相容性

正如擴充套件模組中指出的，許多擴充套件在多個直譯器中（以及在每個直譯器 GIL 下）都能正常工作，而無需進行任何更改。如果此類模組未明確指示支援，匯入系統仍將失敗。最初，許多擴充套件模組都不會這樣做，因此這可能是令人沮喪的來源。

我們將透過新增一個上下文管理器來解決這個問題，以暫時停用對多直譯器支援的檢查：importlib.util.allow_all_extensions()。或多或少，它將修改當前“PyInterpreterState.strict_extension_compat”的值（例如，透過一個私有的 sys 函式）。

擴充套件模組執行緒安全

如果一個模組支援與多個直譯器一起使用，那主要意味著即使這些直譯器不共享 GIL，它也能正常工作。唯一的例外是當模組連結到一個內部全域性狀態非執行緒安全的庫時。（即使是像靜態區域性變數作為臨時緩衝區這樣無害的東西也可能是一個問題。）有了共享的 GIL，該狀態受到保護。如果沒有，此類模組必須使用鎖包裝對該狀態的任何使用（例如透過呼叫）。

目前尚不清楚支援多直譯器是否與支援每個直譯器的 GIL 充分等效，以至於我們可以避免任何特殊安排。這仍然是一個有意義的討論和調查點。兩者之間的實際區別（在 Python 社群中，例如 PyPI）尚未完全理解，無法解決此問題。同樣，尚不清楚我們能做些什麼來幫助擴充套件維護者緩解問題（假設這是一個問題）。

與此同時，我們必須假設這種差異足以給現有足夠多的擴充套件模組帶來問題。我們將採用的解決方案是：

• 新增一個 PyModuleDef 槽位，指示擴充套件可以在每個直譯器 GIL 下匯入（即選擇加入）
• 將該槽位作為“相容”擴充套件定義的一部分，如前所述

缺點是，如果沒有模組維護者額外付出努力，即使是微小的努力，任何擴充套件模組都無法利用每個直譯器 GIL。這使得擴充套件模組相容性中描述的問題更加複雜，並且適用相同的解決方法。理想情況下，我們會確定差異不足以構成問題。

如果最終我們確實要求在每個直譯器 GIL 下匯入時選擇加入，並且稍後確定沒有必要，那麼我們可以屆時切換預設設定，使舊的選擇加入槽位成為空操作，並新增一個新的 PyModuleDef 槽位用於明確選擇 *退出*。事實上，從一開始就新增該選擇退出槽位是很有意義的。

擴充套件模組

目前，Python 最常見的用法是主直譯器單獨執行。本提案對這種場景下的擴充套件模組沒有任何影響。同樣，無論好壞，使用現有 Py_NewInterpreter() 建立的多個直譯器下的行為沒有改變。

請記住，一些擴充套件在多個直譯器中使用時已經出現問題，因為它們將模組狀態儲存在全域性變數中（或由於連結庫的內部狀態）。它們可能會崩潰，甚至更糟，出現不一致的行為。這正是PEP 630 等提案的動機之一，因此這不是一個新的情況，也不是本提案的後果。

相反，當使用提議的 API 並使用適當設定建立多個直譯器時，不相容擴充套件的行為將發生變化。在這種情況下，匯入此類擴充套件將失敗（在主直譯器之外），如限制擴充套件模組中所述。對於已經在多個直譯器中崩潰的擴充套件，這將是一個改進。

此外，一些擴充套件模組連結到具有非執行緒安全內部全域性狀態的庫。（參見擴充套件模組執行緒安全。）此類模組將不得不開始用鎖包裝對該狀態的任何直接或間接使用。這是與也實現多階段初始化並因此指示支援多直譯器（即隔離）的其他模組的關鍵區別。

現在我們來談談上面提到的相容性問題。有些擴充套件在多個直譯器下（以及在每個直譯器的 GIL 下）是安全的，儘管它們沒有表明這一點。不幸的是，匯入系統無法可靠地推斷出此類擴充套件是安全的，因此匯入它們仍將失敗。這種情況在上面的擴充套件模組相容性中有所解決。

C-API 中公開的物件

C-API（包括受限 API）公開了所有內建型別，包括內建異常，以及內建單例。異常以 PyObject * 的形式公開，但其餘以靜態值而非指標的形式公開。這是我們必須為每個直譯器 GIL 解決的少數非平凡問題之一。

有了不朽物件，這就不再是個問題了。

整合的好處

整合全域性變數有多種好處：

• 大大減少了 C 全域性變數的數量（C 程式碼的最佳實踐）
• 此舉將執行時狀態不穩定或損壞的情況提請注意
• 鼓勵執行時狀態使用方式更加一致
• 更容易發現/識別 CPython 的執行時狀態
• 更容易以一致的方式靜態分配執行時狀態
• 更好的執行時狀態記憶體區域性性

此外，上面間接好處中列出的所有好處也適用於此處，並且那裡列出的相同專案也會受益。

工作量

需要移動的全域性變數數量足夠大，但大多數是 Python 物件，可以大量處理（如 Py_IDENTIFIER）。在幾乎所有情況下，將這些全域性變數移至直譯器都是高度機械化的。這不需要巧妙，而是需要有人投入時間。

待移動的狀態

其餘全域性變數可分類如下：

• 全域性物件
  • 靜態型別（包括異常型別）
  • 非靜態型別（包括堆型別、structseq 型別）
  • 單例（靜態）
  • 單例（一次初始化）
  • 快取物件
• 非物件
  • 初始化後不會（或不太可能）更改
  • 僅在主執行緒中使用
  • 延遲初始化
  • 預分配緩衝區
  • 狀態

這些全域性變數分散在核心執行時、內建模組和標準庫擴充套件模組之間。

要了解剩餘全域性變數的詳細分類，請執行：

./python Tools/c-analyzer/table-file.py Tools/c-analyzer/cpython/globals-to-fix.tsv

已完成的工作

如前所述，這項工作已經進行了多年。以下是一些已經完成的事情：

• 執行時初始化清理（參見 PEP 432 / PEP 587）
• 擴充套件模組隔離機制（參見 PEP 384 / PEP 3121 / PEP 489）
• 許多內建模組的隔離
• 許多標準庫擴充套件模組的隔離
• 添加了 _PyRuntimeState
• 不再有 _Py_IDENTIFIER()
• 靜態分配
  • 空字串
  • 字串字面量
  • 識別符號
  • latin-1 字串
  • 長度為 1 的位元組
  • 空元組

工具

如前所述，有幾個工具可以幫助識別全域性變數並對其進行推理。

• Tools/c-analyzer/cpython/globals-to-fix.tsv - 剩餘全域性變數列表
• Tools/c-analyzer/c-analyzer.py
  • analyze - 識別所有全域性變數
  • check - 如果存在任何未被忽略的不支援的全域性變數，則失敗
• Tools/c-analyzer/table-file.py - 彙總已知全域性變數

此外，對不支援的全域性變數的檢查已整合到 CI 中，以防止意外新增新的全域性變數。

全域性物件

可以安全地在直譯器之間共享（無需 GIL）的全域性物件可以保留在 _PyRuntimeState 上。物件不僅必須是實際不可變的（例如單例、字串），而且即使引用計數也不能更改，才能保證安全。不朽物件 (PEP 683) 提供了這一點。（另一種選擇是根本不共享物件，這會大大增加解決方案的複雜性，特別是對於在公共 C-API 中公開的物件。）

內建靜態型別是全域性物件的一種特殊情況，它們將被共享。除了一個部分外，它們實際上是不可變的：__subclasses__（又稱 tp_subclasses）。我們預期內建型別的其他任何部分都不會改變，即使是 __dict__（又稱 tp_dict）的內容也不會改變。

內建型別的 __subclasses__ 將透過將其設定為一個 getter 來處理，該 getter 在當前 PyInterpreterState 中查詢該型別。