初期化 (initialization)、終了処理 (finalization)、スレッド
**********************************************************

Python 初期化設定 も参照してください。


Python 初期化以前
=================

Python が埋め込まれているアプリケーションでは、他の Python/C API 関数
を使う前に "Py_Initialize()" 関数を呼ばなければなりません。これには例
外として、いくつかの関数と グローバルな設定変数 があります。

次の関数は Python の初期化の前でも安全に呼び出せます:

* 設定関数:

  * "PyImport_AppendInittab()"

  * "PyImport_ExtendInittab()"

  * "PyInitFrozenExtensions()"

  * "PyMem_SetAllocator()"

  * "PyMem_SetupDebugHooks()"

  * "PyObject_SetArenaAllocator()"

  * "Py_SetPath()"

  * "Py_SetProgramName()"

  * "Py_SetPythonHome()"

  * "Py_SetStandardStreamEncoding()"

  * "PySys_AddWarnOption()"

  * "PySys_AddXOption()"

  * "PySys_ResetWarnOptions()"

* 情報取得の関数:

  * "Py_IsInitialized()"

  * "PyMem_GetAllocator()"

  * "PyObject_GetArenaAllocator()"

  * "Py_GetBuildInfo()"

  * "Py_GetCompiler()"

  * "Py_GetCopyright()"

  * "Py_GetPlatform()"

  * "Py_GetVersion()"

* ユーティリティ:

  * "Py_DecodeLocale()"

* メモリアロケータ:

  * "PyMem_RawMalloc()"

  * "PyMem_RawRealloc()"

  * "PyMem_RawCalloc()"

  * "PyMem_RawFree()"

注釈:

  次の関数は "Py_Initialize()" より前に **呼び出すべき ではありません
  ** : "Py_EncodeLocale()", "Py_GetPath()", "Py_GetPrefix()",
  "Py_GetExecPrefix()", "Py_GetProgramFullPath()",
  "Py_GetPythonHome()", "Py_GetProgramName()", "PyEval_InitThreads()"
  。


グローバルな設定変数
====================

Python には、様々な機能やオプションを制御するグローバルな設定のための
変数があります。 デフォルトでは、これらのフラグは コマンドラインオプシ
ョン で制御されます。

オプションでフラグがセットされると、フラグの値はそのオプションがセット
された回数になります。 例えば、 "-b" では "Py_BytesWarningFlag" が 1
に設定され、 "-bb" では "Py_BytesWarningFlag" が 2 に設定されます。

int Py_BytesWarningFlag

   "bytes" または "bytearray" を "str" と比較した場合、または、
   "bytes" を "int" と比較した場合に警告を発生させます。 "2" 以上の値
   を設定している場合は、エラーを発生させます。

   "-b" オプションで設定します。

int Py_DebugFlag

   パーサーのデバッグ出力を有効にします。(専門家専用です。コンパイルオ
   プションに依存します)。

   "-d" オプションと "PYTHONDEBUG" 環境変数で設定します。

int Py_DontWriteBytecodeFlag

   非ゼロに設定した場合、Python はソースモジュールのインポート時に
   ".pyc" ファイルの作成を試みません。

   "-B" オプションと "PYTHONDONTWRITEBYTECODE" 環境変数で設定します。

int Py_FrozenFlag

   "Py_GetPath()" の中でモジュール検索パスを割り出しているときのエラー
   メッセージを抑制します。

   "_freeze_importlib" プログラムと "frozenmain" プログラムが使用する
   非公開フラグです。

int Py_HashRandomizationFlag

   "PYTHONHASHSEED" 環境変数が空でない文字列に設定された場合に、 "1"
   が設定されます。

   フラグがゼロでない場合、 "PYTHONHASHSEED" 環境変数を読みシークレッ
   トハッシュシードを初期化します。

int Py_IgnoreEnvironmentFlag

   全ての "PYTHON*" 環境変数を無視します。例えば、 "PYTHONPATH" や
   "PYTHONHOME" などです。

   "-E" オプションと "-I" オプションで設定します。

int Py_InspectFlag

   最初の引数にスクリプトが指定されたときや "-c" オプションが利用され
   た際に、 "sys.stdin" がターミナルに出力されないときであっても、スク
   リプトかコマンドを実行した後にインタラクティブモードに入ります。

   "-i" オプションと "PYTHONINSPECT" 環境変数で設定します。

int Py_InteractiveFlag

   "-i" オプションで設定します。

int Py_IsolatedFlag

   Python を隔離モードで実行します。 隔離モードでは "sys.path" はスク
   リプトのディレクトリやユーザのサイトパッケージのディレクトリを含み
   ません。

   "-I" オプションで設定します。

   バージョン 3.4 で追加.

int Py_LegacyWindowsFSEncodingFlag

   フラグがゼロでない場合は、ファイルシステムエンコーディングに UTF-8
   エンコーディングの代わりに "mbcs" エンコーディングが使われます。

   "PYTHONLEGACYWINDOWSFSENCODING" 環境変数が空でない文字列に設定され
   た場合に、 "1" に設定されます。

   より詳しくは **PEP 529** を参照してください。

   利用可能な環境: Windows 。

int Py_LegacyWindowsStdioFlag

   フラグがゼロでない場合、 "WindowsConsoleIO" の代わりに "io.FileIO"
   を "sys" の標準ストリームとして使います。

   "PYTHONLEGACYWINDOWSSTDIO" 環境変数が空でない文字列に設定された場合
   に、 "1" に設定されます。

   より詳しくは **PEP 528** を参照してください。

   利用可能な環境: Windows 。

int Py_NoSiteFlag

   "site" モジュールの import と、そのモジュールが行なっていた site ご
   との "sys.path" への操作を無効にします。後で "site" を明示的に
   import しても、これらの操作は実行されません (実行したい場合は、
   "site.main()" を呼び出してください)。

   "-S" オプションで設定します。

int Py_NoUserSiteDirectory

   "ユーザのサイトパッケージのディレクトリ" を "sys.path" に追加しませ
   ん。

   "-s" オプション、 "-I" 、 "PYTHONNOUSERSITE" 環境変数で設定します。

int Py_OptimizeFlag

   "-O" オプションと "PYTHONOPTIMIZE" 環境変数で設定します。

int Py_QuietFlag

   インタラクティブモードでも copyright とバージョンのメッセージを表示
   しません。

   "-q" オプションで設定します。

   バージョン 3.2 で追加.

int Py_UnbufferedStdioFlag

   標準出力と標準エラーをバッファリングしないように強制します。

   "-u" オプションと "PYTHONUNBUFFERED" 環境変数で設定します。

int Py_VerboseFlag

   モジュールが初期化されるたびにメッセージを出力し、それがどこ (ファ
   イル名やビルトインモジュール) からロードされたのかを表示します。 値
   が 2 以上の場合は、モジュールを検索するときにチェックしたファイルご
   とにメッセージを出力します。また、終了時のモジュールクリーンアップ
   に関する情報も提供します。

   "-v" オプションと "PYTHONVERBOSE" 環境変数で設定します。


インタープリタの初期化と終了処理
================================

void Py_Initialize()

   Python インタープリタを初期化します。 Python の埋め込みを行うアプリ
   ケーションでは、他のあらゆる Python/C API を使用するよりも前にこの
   関数を呼び出さなければなりません。いくつかの例外については Python
   初期化以前 を参照してください。

   この関数はロード済みモジュールのテーブル ("sys.modules") を初期化し
   、基盤となるモジュール群、 "builtins", "__main__", "sys" を生成しま
   す。また、モジュール検索パス ("sys.path") も初期化します。
   "sys.argv" の設定は行いません。設定するには、 "PySys_SetArgvEx()"
   を使ってください。この関数を ("Py_FinalizeEx()" を呼ばずに) 再度呼
   び出しても何も行いません。戻り値はありません。初期化が失敗すれば、
   それは致命的なエラーです。

   注釈:

     Windows では "O_TEXT" から "O_BINARY" へコンソールモードが変更さ
     れますが、これはその C ランタイムを使っているコンソールでの
     Python 以外の使い勝手にも影響を及ぼします。

void Py_InitializeEx(int initsigs)

   *initsigs* に "1" を指定した場合、この関数は "Py_Initialize()" と同
   じように動作します。 *initsigs* に "0" を指定した場合、初期化時のシ
   グナルハンドラの登録をスキップすることができ、これは Python の埋め
   込みで便利でしょう。

int Py_IsInitialized()

   Python インタプリタが初期化済みであれば真(非ゼロ)を、さもなければ偽
   (ゼロ)を返します。"Py_FinalizeEx()" を呼び出した後は、
   "Py_Initialize()" を再び呼び出すまで、この関数は偽を返します。

int Py_FinalizeEx()

   "Py_Initialize()" とそれ以後の Python/C API 関数で行った全ての初期
   化処理を取り消し、最後の "Py_Initialize()"  呼び出し以後に Python
   インタプリタが生成した全てのサブインタプリタ  (sub-interpreter, 下
   記の "Py_NewInterpreter()" を参照) を消去します。 理想的な状況では
   、この関数によって Python インタプリタが確保したメモリは全て解放さ
   れます。 この関数を ("Py_Initialize()" を呼ばずに) 再度呼び出しても
   何も行いません。 通常は返り値は "0" です。終了処理中 (バッファリン
   グされたデータの書き出し) のエラーがあった場合は "-1" が返されます
   。

   この関数が提供されている理由はいくつかあります。Python の埋め込みを
   行っているアプリケーションでは、アプリケーションを再起動することな
   く Python を再起動したいことがあります。また、動的ロード可能イブラ
   リ (あるいは DLL) から Python インタプリタをロードするアプリケーシ
   ョンでは、DLL をアンロードする前に Python が確保したメモリを全て解
   放したいと考えるかもしれません。アプリケーション内で起きているメモ
   リリークを追跡する際に、開発者は Python が確保したメモリをアプリケ
   ーションの終了前に解放させたいと思う場合もあります。

   **バグおよび注意事項:** モジュールやモジュール内のオブジェクトはラ
   ンダムな順番で削除されます。このため、他のオブジェクト(関数オブジェ
   クトも含みます) やモジュールに依存するデストラクタ  ("__del__()" メ
   ソッド) が失敗してしまうことがあります。動的にロードされるようにな
   っている拡張モジュールが Python によってロードされていた場合、アン
   ロードされません。 Python が確保したメモリがわずかながら解放されな
   いかもしれません (メモリリークを発見したら、どうか報告してください)
   。オブジェクト間の循環参照に捕捉されているメモリは解放されないこと
   があります。拡張モジュールが確保したメモリは解放されないことがあり
   ます。拡張モジュールによっては、初期化ルーチンを 2 度以上呼び出すと
   正しく動作しないことがあります。こうした状況は、 "Py_Initialize()"
   や "Py_FinalizeEx()" を 2 度以上呼び出すと起こり得ます。

   引数無しで 監査イベント "cpython._PySys_ClearAuditHooks" を送出しま
   す。

   バージョン 3.6 で追加.

void Py_Finalize()

   この関数は "Py_FinalizeEx()" の後方互換性バージョンで、戻り値があり
   ません。


プロセスワイドのパラメータ
==========================

int Py_SetStandardStreamEncoding(const char *encoding, const char *errors)

   もし "Py_Initialize()" が呼ばれるなら、この関数はその前に呼ばなけれ
   ばなりません。標準の IO において、どのエンコーディングおよびどんな
   エラー処理を使うかを、 "str.encode()" と同様の意味で指定します。

   これは、環境変数が働かない時に "PYTHONIOENCODING" の値を上書きし、
   埋め込みコードが IO エンコーディングをコントロールできるようにしま
   す。

   *encoding* と *errors* のどちらかまたは両方を "NULL" にすることで、
   "PYTHONIOENCODING" とデフォルト値のどちらかまたは両方を使うことがで
   きます (他の設定に依存します)。

   この設定 (あるいは他の設定) に関わらず、 "sys.stderr" は常に
   "backslashreplace" エラーハンドラを使うことに注意してください。

   "Py_FinalizeEx()" を呼び出した場合は、"Py_Initialize()" を呼び出す
   前に、この関数を再度呼び出す必要があるでしょう。

   成功したら "0" を、エラーの場合は "0" でない値を返します (例えば、
   インタプリタが初期化された後に、この関数が呼び出された場合)。

   バージョン 3.4 で追加.

void Py_SetProgramName(const wchar_t *name)

   この関数を呼び出すなら、最初に "Py_Initialize()" を呼び出すよりも前
   に呼び出さなければなりません。この関数はインタプリタにプログラムの
   "main()" 関数に指定した "argv[0]" 引数の値を教えます (ワイドキャラ
   クタに変換されます)。この引数値は、 "Py_GetPath()" や、以下に示すそ
   の他の関数が、インタプリタの実行可能形式から Python ランタイムライ
   ブラリへの相対パスを取得するために使われます。デフォルトの値は
   "'python'" です。引数はゼロ終端されたワイドキャラクタ文字列で、静的
   な記憶領域に入っていなければならず、その内容はプログラムの実行中に
   変更してはなりません。 Python インタプリタ内のコードで、この記憶領
   域の内容を変更するものは一切ありません。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

wchar* Py_GetProgramName()

   "Py_SetProgramName()" で設定されたプログラム名か、デフォルトのプロ
   グラム名を返します。関数が返す文字列ポインタは静的な記憶領域を返し
   ます。関数の呼び出し側はこの値を変更できません。

wchar_t* Py_GetPrefix()

   プラットフォーム非依存のファイル群がインストールされている場所であ
   る *prefix* を返します。この値は "Py_SetProgramName()" でセットされ
   たプログラム名やいくつかの環境変数をもとに、数々の複雑な規則から導
   出されます。例えば、プログラム名が "'/usr/local/bin/python'" の場合
   、prefix は "'/usr/local'" になります。関数が返す文字列ポインタは静
   的な記憶領域を返します; 関数の呼び出し側はこの値を変更できません。
   この値はトップレベルの "Makefile" に指定されている変数 **prefix**
   や、ビルド値に **configure** スクリプトに指定した "--prefix" 引数に
   対応しています。この値は Python コードからは "sys.prefix" として利
   用できます。これはUnixでのみ有用です。次に説明する関数も参照してく
   ださい。

wchar_t* Py_GetExecPrefix()

   プラットフォーム *依存* のファイルがインストールされている場所であ
   る *exec-prefix* を返します。この値は "Py_SetProgramName()" でセッ
   トされたプログラム名やいくつかの環境変数をもとに、数々の複雑な規則
   から導出されます。例えば、プログラム名が "'/usr/local/bin/python'"
   の場合、exec-prefix は "'/usr/local'" になります。関数が返す文字列
   ポインタは静的な記憶領域を返します; 関数の呼び出し側はこの値を変更
   できません。この値はトップレベルの "Makefile" に指定されている変数
   **exec_prefix** や、ビルド値に **configure** スクリプトに指定した "
   --exec-prefix" 引数に対応しています。この値は Python コードからは
   "sys.exec_prefix" として利用できます。 Unixのみで有用です。

   背景: プラットフォーム依存のファイル (実行形式や共有ライブラリ) が
   別のディレクトリツリー内にインストールされている場合、 exec-prefix
   は prefix と異なります。典型的なインストール形態では、プラットフォ
   ーム非依存のファイルが "/usr/local" に収められる一方、プラットフォ
   ーム依存のファイルは "/usr/local/plat" サブツリーに収められます。

   一般的に、プラットフォームとは、ハードウェアとソフトウェアファミリ
   の組み合わせを指します。例えば、Solaris 2.x を動作させている Sparc
   マシンは全て同じプラットフォームであるとみなしますが、Solaris 2.x
   を動作させている Intel マシンは違うプラットフォームになりますし、同
   じ Intel マシンでも Linux を動作させているならまた別のプラットフォ
   ームです。一般的には、同じオペレーティングシステムでも、メジャーリ
   ビジョンの違うものは異なるプラットフォームです。非 Unix のオペレー
   ティングシステムの場合は話はまた別です; 非 Unix のシステムでは、イ
   ンストール方法はとても異なっていて、prefix や exec-prefix には意味
   がなく、空文字列が設定されています。コンパイル済みの Python バイト
   コードはプラットフォームに依存しないので注意してください (ただし、
   どのバージョンの Python でコンパイルされたかには依存します!)。

   システム管理者は、 **mount** や **automount** プログラムを使って、
   各プラットフォーム用の "/usr/local/plat" を異なったファイルシステム
   に置き、プラットフォーム間で "/usr/local" を共有するための設定方法
   を知っているでしょう。

wchar_t* Py_GetProgramFullPath()

   Python 実行可能形式の完全なプログラム名を返します; この値はデフォル
   トのモジュール検索パスを (前述の "Py_SetProgramName()"  で設定され
   た) プログラム名から導出する際に副作用的に計算されます。関数が返す
   文字列ポインタは静的な記憶領域を返します; 関数の呼び出し側はこの値
   を変更できません。この値は Python コードからは "sys.executable" と
   して利用できます。

wchar_t* Py_GetPath()

   デフォルトのモジュール検索パスを返します; パスは (上の
   "Py_SetProgramName()" で設定された) プログラム名と、いくつかの環境
   変数から計算されます。戻り値となる文字列は、プラットフォーム依存の
   パス区切り文字で分割された一連のディレクトリ名からなります。区切り
   文字は Unix と Mac OS X では "':'", Windows では "';'" です。関数が
   返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し側はこ
   の値を変更できません。 "sys.path" はインタプリタによってこの値で初
   期化され、その後にモジュールをロードする際の検索パスを変更するため
   に修正することが可能で、たいていそうされます。

void Py_SetPath(const wchar_t *)

   デフォルトのモジュール検索パスを設定します。この関数が
   "Py_Initialize()" より前に呼び出された場合、 "Py_GetPath()" はデフ
   ォルトの検索パスを計算しようとせず、代わりにこの関数が与えた検索パ
   スを返します。これは、 Python がアプリケーションに組み込まれていて
   、そのアプリケーションが全てのモジュールの場所を完全に把握している
   ときに便利です。パスはプラットフォーム依存の区切り文字で分割されて
   いる必要があります。区切り文字は Unix と Mac OS X では "':'" 、
   Windows では "';'" です。

   This also causes "sys.executable" to be set to the program full
   path (see "Py_GetProgramFullPath()") and for "sys.prefix" and
   "sys.exec_prefix" to be empty.  It is up to the caller to modify
   these if required after calling "Py_Initialize()".

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

   パス引数は内部でコピーされます。したがって、呼び出し完了後に呼び出
   し元は引数を解放できます。

   バージョン 3.8 で変更: プログラムの名前に代わって、プログラムのフル
   パスが:data:*sys.executable* に使われるようになりました。

const char* Py_GetVersion()

   Python インタプリタのバージョンを返します。バージョンは、次のような
   形式の文字列です

      "3.0a5+ (py3k:63103M, May 12 2008, 00:53:55) \n[GCC 4.2.3]"

   第一ワード (最初のスペース文字まで) は、現在の Python のバージョン
   です; 最初の三文字は、ピリオドで区切られたメジャーバージョンとマイ
   ナーバージョンです。関数が返す文字列ポインタは静的な記憶領域を返し
   ます; 関数の呼び出し側はこの値を変更できません。この値は Python コ
   ードからは "sys.version" として利用できます。

const char* Py_GetPlatform()

   現在のプラットフォームのプラットフォーム識別文字列を返します。Unix
   では、オペレーティングシステムの "公式の" 名前を小文字に変換し、後
   ろにメジャーリビジョン番号を付けた構成になっています。例えば
   Solaris 2.x は、SunOS 5.x, としても知られていますが、"'sunos5'" に
   なります。Mac OS X では "'darwin'" です。Windows では "'win'" です
   。関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出
   し側はこの値を変更できません。この値は Python コードからは
   "sys.platform" として利用できます。

const char* Py_GetCopyright()

   現在の Python バージョンに対する公式の著作権表示文字列を返します。
   例えば

   "'Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam'"

   関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し
   側はこの値を変更できません。この値は Python コードからは
   "sys.copyright" として利用できます。

const char* Py_GetCompiler()

   現在使っているバージョンの Python をビルドする際に用いたコンパイラ
   を示す文字列を、角括弧で囲った文字列を返します。例えば:

      "[GCC 2.7.2.2]"

   関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し
   側はこの値を変更できません。この値は Python コードからは
   "sys.version" の一部として取り出せます。

const char* Py_GetBuildInfo()

   現在使っている Python インタプリタインスタンスの、シーケンス番号と
   ビルド日時に関する情報を返します。例えば

      "#67, Aug  1 1997, 22:34:28"

   関数が返す文字列ポインタは静的な記憶領域を返します; 関数の呼び出し
   側はこの値を変更できません。この値は Python コードからは
   "sys.version" の一部として取り出せます。

void PySys_SetArgvEx(int argc, wchar_t **argv, int updatepath)

   *argc* および *argv* に基づいて "sys.argv" を設定します。これらの引
   数はプログラムの "main()" に渡した引数に似ていますが、最初の要素が
   Python インタプリタの宿主となっている実行形式の名前ではなく、実行さ
   れるスクリプト名を参照しなければならない点が違います。実行するスク
   リプトがない場合、 *argv* の最初の要素は空文字列にしてもかまいませ
   ん。この関数が "sys.argv" の初期化に失敗した場合、致命的エラーを
   "Py_FatalError()" で知らせます。

   *updatepath* が 0 の場合、ここまでの動作がこの関数がすることの全て
   です。 *updatepath* が 0 でない場合、この関数は "sys.path" を以下の
   アルゴリズムに基づいて修正します:

   * 存在するスクリプトの名前が "argv[0]" に渡された場合、そのスクリプ
     トがある場所の絶対パスを "sys.path" の先頭に追加します。

   * それ以外の場合 (*argc* が "0" だったり、 "argv[0]" が存在するファ
     イル名を指していない場合)、 "sys.path" の先頭に空の文字列を追加し
     ます。 これは現在の作業ディレクトリ (""."") を先頭に追加するのと
     同じです。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

   注釈:

     単一のスクリプトを実行する以外の目的でPython インタプリタを埋め込
     んでいるアプリケーションでは、 *updatepath* に "0" を渡して、必要
     な場合は自分で "sys.path" を更新することをおすすめします。
     CVE-2008-5983 を参照してください。3.1.3 より前のバージョンでは、
     "PySys_SetArgv()" の呼び出しが完了した後に "sys.path" の先頭の要
     素を取り出すことで、同じ効果が得られます。例えばこのように使いま
     す:

        PyRun_SimpleString("import sys; sys.path.pop(0)\n");

   バージョン 3.1.3 で追加.

void PySys_SetArgv(int argc, wchar_t **argv)

   この関数は、 **python** インタプリタが "-I" オプション付きで実行さ
   れている場合を除き "PySys_SetArgvEx()" の *updatepath* に "1" を設
   定したのと同じように動作します。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

   バージョン 3.4 で変更: *updatepath* の値は "-I" オプションに依存し
   ます。

void Py_SetPythonHome(const wchar_t *home)

   Python の標準ライブラリがある、デフォルトの "home" ディレクトリを設
   定します。引数の文字列の意味については "PYTHONHOME" を参照してくだ
   さい。

   引数は静的なストレージに置かれてプログラム実行中に書き換えられない
   ようなゼロ終端の文字列であるべきです。Python インタプリタはこのスト
   レージの内容を変更しません。

   バイト文字列を "wchar_*" 文字列にデコードするには
   "Py_DecodeLocale()" を使ってください。

w_char* Py_GetPythonHome()

   前回の "Py_SetPythonHome()" 呼び出しで設定されたデフォルトの "home"
   か、 "PYTHONHOME" 環境変数が設定されていればその値を返します。


スレッド状態 (thread state) とグローバルインタプリタロック (global interpreter lock)
====================================================================================

Python インタプリタは完全にはスレッドセーフではありません。マルチスレ
ッドの Python プログラムをサポートするために、 *グローバルインタプリタ
ロック* あるいは *GIL* と呼ばれるグローバルなロックが存在していて、現
在のスレッドが Python オブジェクトに安全にアクセスする前に必ずロックを
獲得しなければならなくなっています。ロック機構がなければ、単純な操作で
さえ、マルチスレッドプログラムの実行に問題を引き起こす可能性があります
。たとえば、二つのスレッドが同じオブジェクトの参照カウントを同時にイン
クリメントすると、結果的に参照カウントは二回でなく一回だけしかインクリ
メントされないかもしれません。

このため、 *GIL* を獲得したスレッドだけが Python オブジェクトを操作し
たり、 Python/C API 関数を呼び出したりできるというルールがあります。並
行処理をエミュレートするために、インタプリタは定期的にロックを解放した
り獲得したりします。 ("sys.setswitchinterval()" を参照) このロックはブ
ロックが起こりうる I/O 操作の付近でも解放・獲得され、 I/O を要求するス
レッドが I/O 操作の完了を待つ間、他のスレッドが動作できるようにしてい
ます。

Python インタプリタはスレッドごとに必要な情報を "PyThreadState" と呼ば
れるデータ構造の中に保存します。そしてグローバル変数として現在の
"PyThreadState" を指すポインタを1つ持ちます。このグローバル変数は
"PyThreadState_Get()" を使って取得できます。


拡張コード内で GIL を解放する
-----------------------------

*GIL* を操作するほとんどのコードは、次のような単純な構造になります:

   Save the thread state in a local variable.
   Release the global interpreter lock.
   ... Do some blocking I/O operation ...
   Reacquire the global interpreter lock.
   Restore the thread state from the local variable.

この構造は非常に一般的なので、作業を単純にするために2つのマクロが用意
されています:

   Py_BEGIN_ALLOW_THREADS
   ... Do some blocking I/O operation ...
   Py_END_ALLOW_THREADS

"Py_BEGIN_ALLOW_THREADS" マクロは新たなブロックを開始し、隠しローカル
変数を宣言します; "Py_END_ALLOW_THREADS" はブロックを閉じます。

上のブロックは次のコードに展開されます:

   PyThreadState *_save;

   _save = PyEval_SaveThread();
   ... Do some blocking I/O operation ...
   PyEval_RestoreThread(_save);

これらの関数の動作を説明します。GIL は現在のスレッド状態を指すポインタ
を保護するために使われます。ロックを解放してスレッド状態を退避する際、
ロックを解放する前に現在のスレッド状態ポインタを取得しておかなければな
りません (他のスレッドがすぐさまロックを獲得して、自らのスレッド状態を
グローバル変数に保存してしまうかもしれないからです)。逆に、ロックを獲
得してスレッド状態を復帰する際には、グローバル変数にスレッド状態ポイン
タを保存する前にロックを獲得しておかなければなりません。

注釈:

  GIL を解放するのはほとんどがシステムのI/O関数を呼び出す時ですが、メ
  モリバッファに対する圧縮や暗号化のように、 Python のオブジェクトにア
  クセスしない長時間かかる計算処理を呼び出すときも GIL を解放すること
  は有益です。例えば、 "zlib" や "hashlib" モジュールは圧縮やハッシュ
  計算の前に GIL を解放します。


Python 以外で作られたスレッド
-----------------------------

Python API を通して作られたスレッド ("threading" モジュールなど) では
自動的にスレッド状態が割り当てられて、上記のコードは正しく動きます。し
かし、(自前でスレッド管理を行う外部のライブラリなどにより)C言語でスレ
ッドを生成した場合、そのスレッドには GIL がなく、スレッド状態データ構
造体もないことに注意する必要があります。

このようなスレッドから Python コードを呼び出す必要がある場合 (外部のラ
イブラリからコールバックするAPIなどがよくある例です)、Python/C API を
呼び出す前に、スレッド状態データ構造体を生成し、GIL を獲得し、スレッド
状態ポインタを保存することで、スレッドをインタプリタに登録しなければな
りません。スレッドが作業を終えたら、スレッド状態ポインタをリセットして
、ロックを解放し、最後にスレッド状態データ構造体のメモリを解放しなけれ
ばなりません。

"PyGILState_Ensure()" と "PyGILState_Release()" はこの処理を自動的に行
います。 Cのスレッドから Python を呼び出す典型的な方法は以下のとおりで
す:

   PyGILState_STATE gstate;
   gstate = PyGILState_Ensure();

   /* Perform Python actions here. */
   result = CallSomeFunction();
   /* evaluate result or handle exception */

   /* Release the thread. No Python API allowed beyond this point. */
   PyGILState_Release(gstate);

"PyGILState_*()" 関数は、("Py_Initialize()" によって自動的に作られる)
グローバルインタプリタ1つだけが存在すると仮定する事に気をつけて下さい
。 Python は ("Py_NewInterpreter()" を使って) 追加のインタプリタを作成
できることに変わりはありませんが、複数インタプリタと "PyGILState_*()"
API を混ぜて使うことはサポートされていません。


Cautions about fork()
---------------------

Another important thing to note about threads is their behaviour in
the face of the C "fork()" call. On most systems with "fork()", after
a process forks only the thread that issued the fork will exist.  This
has a concrete impact both on how locks must be handled and on all
stored state in CPython's runtime.

The fact that only the "current" thread remains means any locks held
by other threads will never be released. Python solves this for
"os.fork()" by acquiring the locks it uses internally before the fork,
and releasing them afterwards. In addition, it resets any Lock オブジ
ェクト in the child. When extending or embedding Python, there is no
way to inform Python of additional (non-Python) locks that need to be
acquired before or reset after a fork. OS facilities such as
"pthread_atfork()" would need to be used to accomplish the same thing.
Additionally, when extending or embedding Python, calling "fork()"
directly rather than through "os.fork()" (and returning to or calling
into Python) may result in a deadlock by one of Python's internal
locks being held by a thread that is defunct after the fork.
"PyOS_AfterFork_Child()" tries to reset the necessary locks, but is
not always able to.

The fact that all other threads go away also means that CPython's
runtime state there must be cleaned up properly, which "os.fork()"
does.  This means finalizing all other "PyThreadState" objects
belonging to the current interpreter and all other
"PyInterpreterState" objects.  Due to this and the special nature of
the "main" interpreter, "fork()" should only be called in that
interpreter's "main" thread, where the CPython global runtime was
originally initialized. The only exception is if "exec()" will be
called immediately after.


高レベルAPI
-----------

C拡張を書いたりPythonインタプリタを埋め込むときに最も一般的に使われる
型や関数は次のとおりです:

PyInterpreterState

   このデータ構造体は、協調動作する多数のスレッド間で共有されている状
   態を表現します。同じインタプリタに属するスレッドはモジュール管理情
   報やその他いくつかの内部的な情報を共有しています。この構造体には公
   開 (public) のメンバはありません。

   異なるインタプリタに属するスレッド間では、利用可能なメモリ、開かれ
   ているファイルデスクリプタなどといったプロセス状態を除いて、初期状
   態では何も共有されていません。GILもまた、スレッドがどのインタプリタ
   に属しているかに関わらずすべてのスレッドで共有されています。

PyThreadState

   This data structure represents the state of a single thread.  The
   only public data member is "interp" ("PyInterpreterState *"), which
   points to this thread's interpreter state.

void PyEval_InitThreads()

   GIL を初期化し、獲得します。この関数は、主スレッドが第二のスレッド
   を生成する以前や、 "PyEval_ReleaseThread(tstate)" といった他のスレ
   ッド操作に入るよりも前に呼び出されるようにしておかなければなりませ
   ん。 "PyEval_SaveThread()", "PyEval_RestoreThread()" の前に呼び出す
   必要はありません。

   二度目に呼び出すと何も行いません。

   バージョン 3.7 で変更: この関数は "Py_Initialize()" から呼び出され
   るようになり、わざわざ呼び出す必要はもう無くなりました。

   バージョン 3.2 で変更: この関数は "Py_Initialize()" より前に呼び出
   すことができなくなりました。

int PyEval_ThreadsInitialized()

   "PyEval_InitThreads()" をすでに呼び出している場合は真 (非ゼロ) を返
   します。この関数は、GILを獲得せずに呼び出すことができますので、シン
   グルスレッドで実行している場合にはロック関連のAPI呼び出しを避けるた
   めに使うことができます。

   バージョン 3.7 で変更: *GIL* が "Py_Initialize()" で初期化されるよ
   うになりました。

PyThreadState* PyEval_SaveThread()

   (GIL が生成されている場合) GILを解放して、スレッドの状態を "NULL"
   にし、以前のスレッド状態 ("NULL" にはなりません) を返します。 ロッ
   クがすでに生成されている場合、現在のスレッドがロックを獲得していな
   ければなりません。

void PyEval_RestoreThread(PyThreadState *tstate)

   (GIL が生成されている場合) GIL を獲得して、現在のスレッド状態を
   *tstate* に設定します。 *tstate* は "NULL" であってはなりません。
   GIL が生成されていて、この関数を呼び出したスレッドがすでにロックを
   獲得している場合、デッドロックに陥ります。

   注釈:

     ランタイムが終了処理をしているときに、スレッドからこの関数を呼び
     出すと、そのスレッドが Python によって作成されたものではなかった
     としても終了させられます。 "_Py_IsFinalizing()" や
     "sys.is_finalizing()" を使うと、この関数を呼び出す前にインタプリ
     タが終了される過程の途中なのか確認でき、望まないスレッドの終了が
     避けられます。

PyThreadState* PyThreadState_Get()

   現在のスレッド状態を返します。GIL を保持していなければなりません。
   現在のスレッド状態が "NULL" なら、(呼び出し側が "NULL" チェックをし
   なくてすむように) この関数は致命的エラーを起こすようになっています
   。

PyThreadState* PyThreadState_Swap(PyThreadState *tstate)

   現在のスレッド状態を *tstate* に指定したスレッド状態と入れ変えます
   。*tstate* は "NULL" の場合があります。GIL を保持していなければなら
   ず、解放しません。

以下の関数はスレッドローカルストレージを利用していて、サブインタプリタ
との互換性がありません:

PyGILState_STATE PyGILState_Ensure()

   Pythonの状態やGILに関わらず、実行中スレッドでPython C APIの呼び出し
   が可能となるようにします。この関数はスレッド内で何度でも呼び出すこ
   とができますが、必ず全ての呼び出しに対応して "PyGILState_Release()"
   を呼び出す必要があります。通常、 "PyGILState_Ensure()" 呼び出しと
   "PyGILState_Release()" 呼び出しの間でこれ以外のスレッド関連API を使
   用することができますが、Release()の前にスレッド状態は復元されていな
   ければなりません。例えば、通常の "Py_BEGIN_ALLOW_THREADS" マクロと
   "Py_END_ALLOW_THREADS" は使用することができます。

   戻り値は "PyGILState_Ensure()" 呼び出し時のスレッド状態を隠蔽した"
   ハンドル"で、 "PyGILState_Release()" に渡してPythonを同じ状態に保た
   なければなりません。再起呼び出しも可能ですが、ハンドルを共有するこ
   とは *できません* - それぞれの "PyGILState_Ensure()" 呼び出しでハン
   ドルを保存し、対応する "PyGILState_Release()" 呼び出しで渡してくだ
   さい。

   関数から復帰したとき、実行中のスレッドはGILを所有していて、任意の
   Python コードを実行できます。処理の失敗は致命的なエラーです。

   注釈:

     ランタイムが終了処理をしているときに、スレッドからこの関数を呼び
     出すと、そのスレッドが Python によって作成されたものではなかった
     としても終了させられます。 "_Py_IsFinalizing()" や
     "sys.is_finalizing()" を使うと、この関数を呼び出す前にインタプリ
     タが終了される過程の途中なのか確認でき、望まないスレッドの終了が
     避けられます。

void PyGILState_Release(PyGILState_STATE)

   獲得したすべてのリソースを解放します。この関数を呼び出すと、Python
   の状態は対応する "PyGILState_Ensure()" を呼び出す前と同じとなります
   (通常、この状態は呼び出し元でははわかりませんので、GILState APIを利
   用するようにしてください)。

   "PyGILState_Ensure()" を呼び出す場合は、必ず同一スレッド内で対応す
   る "PyGILState_Release()" を呼び出してください。

PyThreadState* PyGILState_GetThisThreadState()

   このスレッドの現在のスレッドの状態を取得します。これまで現在のスレ
   ッドで GILState API を使ったことが無い場合は、"NULL" が返ります。メ
   インスレッドで自身のスレッド状態に関する呼び出しを全くしないとして
   も、メインスレッドは常にスレッド状態の情報を持っていることに注意し
   てください。こうなっている目的は主にヘルパ機能もしくは診断機能のた
   めです。

int PyGILState_Check()

   現在のスレッドが GILを保持しているならば "1" を、そうでなければ "0"
   を返します。この関数はいつでもどのスレッドからでも呼び出すことがで
   きます。 Python スレッドの状態が初期化されており、現在 GIL を保持し
   ている場合にのみ "1" を返します。これは主にヘルパー/診断用の関数で
   す。この関数は、例えばコールバックのコンテキストやメモリ割り当て機
   能で有益でしょう。なぜなら、 GIL がロックされていると知っていれば、
   呼び出し元は sensitive な行動を実行することができ、そうでなければ異
   なるやりかたで振る舞うことができるからです。

   バージョン 3.4 で追加.

以下のマクロは、通常末尾にセミコロンを付けずに使います; Python ソース
配布物内の使用例を見てください。

Py_BEGIN_ALLOW_THREADS

   このマクロを展開すると "{ PyThreadState *_save; _save =
   PyEval_SaveThread();" になります。マクロに開き波括弧が入っているこ
   とに注意してください; この波括弧は後で "Py_END_ALLOW_THREADS" マク
   ロと対応させなければなりません。マクロについての詳しい議論は上記を
   参照してください。

Py_END_ALLOW_THREADS

   このマクロを展開すると "PyEval_RestoreThread(_save); }" になります
   。マクロに開き波括弧が入っていることに注意してください; この波括弧
   は事前の "Py_BEGIN_ALLOW_THREADS" マクロと対応していなければなりま
   せん。マクロについての詳しい議論は上記を参照してください。

Py_BLOCK_THREADS

   このマクロを展開すると "PyEval_RestoreThread(_save);" になります:
   閉じ波括弧のない "Py_END_ALLOW_THREADS" と同じです。

Py_UNBLOCK_THREADS

   このマクロを展開すると "_save = PyEval_SaveThread();" になります:
   開き波括弧のない "Py_BEGIN_ALLOW_THREADS" と同じです。


低レベルAPI
-----------

次の全ての関数は "Py_Initialize()" の後に呼び出さなければなりません。

バージョン 3.7 で変更: "Py_Initialize()" は *GIL* を初期化するようにな
りました。

PyInterpreterState* PyInterpreterState_New()

   新しいインタプリタ状態オブジェクトを生成します。GIL を保持しておく
   必要はありませんが、この関数を次々に呼び出す必要がある場合には保持
   しておいたほうがよいでしょう。

   引数無しで 監査イベント "cpython.PyInterpreterState_New" を送出しま
   す。

void PyInterpreterState_Clear(PyInterpreterState *interp)

   インタプリタ状態オブジェクト内の全ての情報をリセットします。GIL を
   保持していなければなりません。

   引数無しで 監査イベント "cpython.PyInterpreterState_Clear" を送出し
   ます。

void PyInterpreterState_Delete(PyInterpreterState *interp)

   インタプリタ状態オブジェクトを破壊します。GIL を保持しておく必要は
   ありません。インタプリタ状態は "PyInterpreterState_Clear()" であら
   かじめリセットしておかなければなりません。

PyThreadState* PyThreadState_New(PyInterpreterState *interp)

   指定したインタプリタオブジェクトに属する新たなスレッド状態オブジェ
   クトを生成します。GIL を保持しておく必要はありませんが、この関数を
   次々に呼び出す必要がある場合には保持しておいたほうがよいでしょう。

void PyThreadState_Clear(PyThreadState *tstate)

   スレッド状態オブジェクト内の全ての情報をリセットします。GIL を保持
   していなければなりません。

void PyThreadState_Delete(PyThreadState *tstate)

   スレッド状態オブジェクトを破壊します。GIL を保持する必要はありませ
   ん。スレッド状態は "PyThreadState_Clear()" であらかじめリセットして
   おかなければなりません。

PY_INT64_T PyInterpreterState_GetID(PyInterpreterState *interp)

   インタプリタの一意な ID を返します。 処理中に何かエラーが起きたら、
   "-1" が返され、エラーがセットされます。

   バージョン 3.7 で追加.

PyObject* PyInterpreterState_GetDict(PyInterpreterState *interp)

   インタプリタ固有のデータを保持している辞書を返します。 この関数が
   "NULL" を返した場合は、ここまでで例外は送出されておらず、呼び出し側
   はインタプリタ固有の辞書は利用できないと考えなければなりません。

   この関数は "PyModule_GetState()" を置き換えるものではなく、拡張モジ
   ュールがインタプリタ固有の状態情報を格納するのに使うべきものです。

   バージョン 3.8 で追加.

PyObject* PyThreadState_GetDict()
    *Return value: Borrowed reference.*

   拡張モジュールがスレッド固有の状態情報を保存できるような辞書を返し
   ます。各々の拡張モジュールが辞書に状態情報を保存するためには唯一の
   キーを使わなければなりません。現在のスレッド状態がない時にこの関数
   を呼び出してもかまいません。この関数が "NULL" を返す場合、例外はま
   ったく送出されず、呼び出し側は現在のスレッド状態が利用できないと考
   えなければなりません。

int PyThreadState_SetAsyncExc(unsigned long id, PyObject *exc)

   スレッド内で非同期的に例外を送出します。 *id* 引数はターゲットとな
   るスレッドのスレッド id です; *exc* は送出する例外オブジェクトです
   。この関数は *exc* に対する参照を一切盗み取りません。安直な間違いを
   防ぐため、この関数を呼び出すには独自に C 拡張モジュールを書かなけれ
   ばなりません。 GIL を保持した状態で呼び出さなければなりません。状態
   が変更されたスレッドの数を返します; 通常は 1 ですが、スレッドが見付
   からなかった場合は 0 になることもあります。 *exc* が "NULL" の場合
   は、このスレッドのまだ送出されていない例外は (何であれ) 消去されま
   す。この場合は例外を送出しません。

   バージョン 3.7 で変更: *id* 引数の型が "long" から "unsigned long"
   へ変更されました。

void PyEval_AcquireThread(PyThreadState *tstate)

   GIL を獲得し、現在のスレッド状態を *tstate* に設定します。 *tstate*
   は "NULL" であってはなりません。ロックはあらかじめ作成されていなけ
   ればなりません。この関数を呼び出したスレッドがすでにロックを獲得し
   ている場合、デッドロックに陥ります。

   注釈:

     ランタイムが終了処理をしているときに、スレッドからこの関数を呼び
     出すと、そのスレッドが Python によって作成されたものではなかった
     としても終了させられます。 "_Py_IsFinalizing()" や
     "sys.is_finalizing()" を使うと、この関数を呼び出す前にインタプリ
     タが終了される過程の途中なのか確認でき、望まないスレッドの終了が
     避けられます。

   バージョン 3.8 で変更: Updated to be consistent with
   "PyEval_RestoreThread()", "Py_END_ALLOW_THREADS()", and
   "PyGILState_Ensure()", and terminate the current thread if called
   while the interpreter is finalizing.

   "PyEval_RestoreThread()" はいつでも (スレッドが初期化されたいないと
   きでも) 利用可能な高レベル関数です。

void PyEval_ReleaseThread(PyThreadState *tstate)

   現在のスレッド状態をリセットして "NULL" にし、GIL を解放します。ロ
   ックはあらかじめ作成されていなければならず、かつ現在のスレッドが保
   持していなければなりません。*tstate* は "NULL" であってはなりません
   が、その値が現在のスレッド状態を表現しているかどうかを調べるために
   だけ使われます --- もしそうでなければ、致命的エラーが報告されます。

   "PyEval_SaveThread()" はより高レベルな関数で常に (スレッドが初期化
   されていないときでも) 利用できます。

void PyEval_AcquireLock()

   GILを獲得します。ロックは前もって作成されていなければなりません。こ
   の関数を呼び出したスレッドがすでにロックを獲得している場合、デッド
   ロックに陥ります。

   バージョン 3.2 で非推奨: この関数は現在のスレッドの状態を更新しませ
   ん。代わりに "PyEval_RestoreThread()" もしくは
   "PyEval_AcquireThread()" を使用してください。

   注釈:

     ランタイムが終了処理をしているときに、スレッドからこの関数を呼び
     出すと、そのスレッドが Python によって作成されたものではなかった
     としても終了させられます。 "_Py_IsFinalizing()" や
     "sys.is_finalizing()" を使うと、この関数を呼び出す前にインタプリ
     タが終了される過程の途中なのか確認でき、望まないスレッドの終了が
     避けられます。

   バージョン 3.8 で変更: Updated to be consistent with
   "PyEval_RestoreThread()", "Py_END_ALLOW_THREADS()", and
   "PyGILState_Ensure()", and terminate the current thread if called
   while the interpreter is finalizing.

void PyEval_ReleaseLock()

   GILを解放します。ロックは前もって作成されていなければなりません。

   バージョン 3.2 で非推奨: この関数は現在のスレッドの状態を更新しませ
   ん。代わりに "PyEval_SaveThread()" もしくは
   "PyEval_ReleaseThread()" を使用してください。


サブインタプリタサポート
========================

ほとんどの場合は埋め込む Python インタプリタは1つだけですが、いくつか
の場合に同一プロセス内、あるいは同一スレッド内で、複数の独立したインタ
プリタを作成する必要があります。 これを可能にするのがサブインタプリタ
です。

"メイン" インタプリタとは、ランタイムが初期化を行ったときに最初に作成
されたインタプリタのことです。 サブインタプリタと違い、メインインタプ
リタにはシグナルハンドリングのような、プロセス全域で唯一な責務がありま
す。 メインインタプリタにはランタイムの初期化中の処理実行という責務も
あり、通常はランタイムの終了処理中に動いているランタイムでもあります。
"PyInterpreterState_Main()" 関数は、メインインタプリタの状態へのポイン
タを返します。

サブインタプリタを切り替えが "PyThreadState_Swap()" 関数でできます。
次の関数を使ってサブインタプリタの作成と削除が行えます:

PyThreadState* Py_NewInterpreter()

   新しいサブインタプリタ (sub-interpreter) を生成します。サブインタプ
   リタとは、(ほぼ完全に) 個別に分割された Python コードの実行環境です
   。特に、新しいサブインタプリタは、 import されるモジュール全てにつ
   いて個別のバージョンを持ち、これには基盤となるモジュール
   "builtins", "__main__" および "sys" も含まれます。ロード済みのモジ
   ュールからなるテーブル ("sys.modules")  およびモジュール検索パス
   ("sys.path") もサブインタプリタ毎に別個のものになります。新たなサブ
   インタプリタ環境には "sys.argv" 変数がありません。また、サブインタ
   プリタは新たな標準 I/O ストリーム "sys.stdin", "sys.stdout",
   "sys.stderr" を持ちます (とはいえ、これらのストリームは根底にある同
   じファイル記述子を参照しています)。

   戻り値は、新たなサブインタプリタが生成したスレッド状態 (thread
   state) オブジェクトのうち、最初のものを指しています。このスレッド状
   態が現在のスレッド状態 (current thread state) になります。実際のス
   レッドが生成されるわけではないので注意してください; 下記のスレッド
   状態に関する議論を参照してください。新たなインタプリタの生成に失敗
   すると、"NULL" を返します; 例外状態はセットされませんが、これは例外
   状態が現在のスレッド状態に保存されることになっていて、現在のスレッ
   ド状態なるものが存在しないことがあるからです。(他の Python/C API 関
   数のように、この関数を呼び出す前にはGILが保持されていなければならず
   、関数が処理を戻した際にも保持されたままになります; しかし、他の
   Python/C API 関数とは違い、関数から戻ったときの現在のスレッド状態が
   関数に入るときと同じとは限らないので注意してください。)

   Extension modules are shared between (sub-)interpreters as follows:

   * For modules using multi-phase initialization, e.g.
     "PyModule_FromDefAndSpec()", a separate module object is created
     and initialized for each interpreter. Only C-level static and
     global variables are shared between these module objects.

   * For modules using single-phase initialization, e.g.
     "PyModule_Create()", the first time a particular extension is
     imported, it is initialized normally, and a (shallow) copy of its
     module's dictionary is squirreled away. When the same extension
     is imported by another (sub-)interpreter, a new module is
     initialized and filled with the contents of this copy; the
     extension's "init" function is not called. Objects in the
     module's dictionary thus end up shared across (sub-)interpreters,
     which might cause unwanted behavior (see Bugs and caveats below).

     Note that this is different from what happens when an extension
     is imported after the interpreter has been completely re-
     initialized by calling "Py_FinalizeEx()" and "Py_Initialize()";
     in that case, the extension's "initmodule" function *is* called
     again. As with multi-phase initialization, this means that only
     C-level static and global variables are shared between these
     modules.

void Py_EndInterpreter(PyThreadState *tstate)

   指定されたスレッド状態 *tstate* で表現される (サブ) インタプリタを
   抹消します。 *tstate* は現在のスレッド状態でなければなりません。下
   記のスレッド状態に関する議論を参照してください。関数呼び出しが戻っ
   たとき、現在のスレッド状態は "NULL" になっています。このインタプリ
   タに関連付けられた全てのスレッド状態は抹消されます。 (この関数を呼
   び出す前にはGILを保持しておかなければならず、ロックは関数が戻ったと
   きも保持されています。) "Py_FinalizeEx()" は、その時点で明示的に抹
   消されていない全てのサブインタプリタを抹消します。


バグと注意事項
--------------

Because sub-interpreters (and the main interpreter) are part of the
same process, the insulation between them isn't perfect --- for
example, using low-level file operations like  "os.close()" they can
(accidentally or maliciously) affect each other's open files.  Because
of the way extensions are shared between (sub-)interpreters, some
extensions may not work properly; this is especially likely when using
single-phase initialization or (static) global variables. It is
possible to insert objects created in one sub-interpreter into a
namespace of another (sub-)interpreter; this should be avoided if
possible.

Special care should be taken to avoid sharing user-defined functions,
methods, instances or classes between sub-interpreters, since import
operations executed by such objects may affect the wrong
(sub-)interpreter's dictionary of loaded modules. It is equally
important to avoid sharing objects from which the above are reachable.

サブインタプリタを "PyGILState_*()" API と組み合わせるのが難しいことに
も注意してください。これらのAPIはPythonのスレッド状態とOSレベルスレッ
ドが1対1で対応していることを前提にしていて、サブインタプリタが存在する
とその前提が崩れるからです。対応する "PyGILState_Ensure()" と
"PyGILState_Release()" の呼び出しのペアの間では、サブインタプリタの切
り替えを行わないことを強く推奨します。さらに、("ctypes" のような)これ
らのAPIを使ってPythonの外で作られたスレッドから Pythonコードを実行して
いる拡張モジュールはサブインタプリタを使うと壊れる可能性があります。


非同期通知
==========

インタプリタのメインスレッドに非同期な通知を行うために提供されている仕
組みです。これらの通知は関数ポインタと void ポインタ引数という形態を取
ります。

int Py_AddPendingCall(int (*func)(void *), void *arg)

   インタプリタのメインスレッドから関数が呼び出される予定を組みます。
   成功すると "0" が返り、*func* はメインスレッドの呼び出しキューに詰
   められます。失敗すると、例外をセットせずに "-1" が返ります。

   無事にキューに詰められると、*func* は *いつかは必ず* インタプリタの
   メインスレッドから、*arg* を引数として呼び出されます。この関数は、
   通常の実行中の Python コードに対して非同期に呼び出されますが、次の
   両方の条件に合致したときに呼び出されます:

   * *bytecode* 境界上にいるとき、

   * メインスレッドが *global interpreter lock* を保持している (すなわ
     ち *func* が全ての C API を呼び出せる) とき。

   成功したら *func* は "0" を返さねばならず、失敗したら "-1" を返し例
   外をセットしなければいけません。*func* は、他の非同期通知を行うため
   に、さらに割り込まれることはありませんが、グローバルインタプリタロ
   ックが解放された場合は、スレッドの切り替えによって割り込まれる可能
   性が残っています。

   この関数は実行するのに現在のスレッド状態を必要とせず、グローバルイ
   ンタプリタロックも必要としません。

   警告:

     これは、非常に特別な場合にのみ役立つ、低レベルな関数です。 *func*
     が可能な限り早く呼び出される保証はありません。メインスレッドがシ
     ステムコールを実行するのに忙しい場合は、 *func* はシステムコール
     が返ってくるまで呼び出されないでしょう。この関数は一般的には、任
     意の C スレッドから Python コードを呼び出すのには **向きません**
     。これの代わりに、 PyGILState API を使用してください。

   バージョン 3.1 で追加.


プロファイルとトレース (profiling and tracing)
==============================================

Python インタプリタは、プロファイル: 分析 (profile) や実行のトレース:
追跡 (trace) といった機能を組み込むために低水準のサポートを提供してい
ます。このサポートは、プロファイルやデバッグ、適用範囲分析 (coverage
analysis) ツールなどに使われます。

この C インタフェースは、プロファイルやトレース作業時に、Python レベル
の呼び出し可能オブジェクトが呼び出されることによるオーバヘッドを避け、
直接 C 関数呼び出しが行えるようにしています。プロファイルやトレース機
能の本質的な特性は変わっていません; インタフェースではトレース関数をス
レッドごとにインストールでき、トレース関数に報告される基本イベント
(basic event) は以前のバージョンにおいて Python レベルのトレース関数で
報告されていたものと同じです。

int (*Py_tracefunc)(PyObject *obj, PyFrameObject *frame, int what, PyObject *arg)

   "PyEval_SetProfile()" および "PyEval_SetTrace()" を使って登録できる
   トレース関数の形式です。最初のパラメタはオブジェクトで、登録関数に
   *obj* として渡されます。 *frame* はイベントが属している実行フレーム
   オブジェクトで、 *what* は定数 "PyTrace_CALL", "PyTrace_EXCEPTION",
   "PyTrace_LINE", "PyTrace_RETURN", "PyTrace_C_CALL",
   "PyTrace_C_RETURN", "PyTrace_OPCODE" のいずれかで、 *arg* は *what*
   の値によって以下のように異なります:

   +--------------------------------+------------------------------------------+
   | *what* の値                    | *arg* の意味                             |
   |================================|==========================================|
   | "PyTrace_CALL"                 | 常に "Py_None" 。                        |
   +--------------------------------+------------------------------------------+
   | "PyTrace_EXCEPTION"            | "sys.exc_info()" の返す例外情報です。    |
   +--------------------------------+------------------------------------------+
   | "PyTrace_LINE"                 | 常に "Py_None" 。                        |
   +--------------------------------+------------------------------------------+
   | "PyTrace_RETURN"               | 呼び出し側に返される予定の値か、例外によ |
   |                                | って関数を抜ける場合は "NULL" です。     |
   +--------------------------------+------------------------------------------+
   | "PyTrace_C_CALL"               | 呼び出される関数オブジェクト。           |
   +--------------------------------+------------------------------------------+
   | "PyTrace_C_EXCEPTION"          | 呼び出される関数オブジェクト。           |
   +--------------------------------+------------------------------------------+
   | "PyTrace_C_RETURN"             | 呼び出される関数オブジェクト。           |
   +--------------------------------+------------------------------------------+
   | "PyTrace_OPCODE"               | 常に "Py_None" 。                        |
   +--------------------------------+------------------------------------------+

int PyTrace_CALL

   関数やメソッドが新たに呼び出されたり、ジェネレータが新たなエントリ
   の処理に入ったことを報告する際の、 "Py_tracefunc" の *what* の値で
   す。イテレータやジェネレータ関数の生成は、対応するフレーム内の
   Python バイトコードに制御の委譲 (control transfer) が起こらないため
   報告されないので注意してください。

int PyTrace_EXCEPTION

   例外が送出された際の "Py_tracefunc" の *what* の値です。現在実行さ
   れているフレームで例外がセットされ、何らかのバイトコードが処理され
   た後に、 *what* にこの値がセットされた状態でコールバック関数が呼び
   出されます。この結果、例外の伝播によって Python が呼び出しスタック
   を逆戻りする際に、各フレームから処理が戻るごとにコールバック関数が
   呼び出されます。トレース関数だけがこれらのイベントを受け取ります;
   プロファイラはこの種のイベントを必要としません。

int PyTrace_LINE

   行番号イベントを報告するときに、 (プロファイル関数ではなく)
   "Py_tracefunc" 関数に *what* 引数として渡す値です。 "f_trace_lines"
   が *0* に設定されたフレームでは無効化されていることもあります。

int PyTrace_RETURN

   呼び出しが返るときに "Py_tracefunc" 関数に *what* 引数として渡す値
   です。

int PyTrace_C_CALL

   C関数を呼び出す直前に "Py_tracefunc" 関数の *what* 引数として渡す値
   です。

int PyTrace_C_EXCEPTION

   C関数が例外を送出したときに "Py_tracefunc" 関数の *what* 引数として
   渡す値です。

int PyTrace_C_RETURN

   C関数から戻るときに "Py_tracefunc" 関数の *what* 引数として渡す値で
   す。

int PyTrace_OPCODE

   新しい opcode が実行されるときに、 (プロファイル関数ではなく)
   "Py_tracefunc" 関数に *what* 引数として渡す値です。 デフォルトでは
   イベントは発火しません。フレーム上で "f_trace_lines" を *1* に設定
   して、明示的に要請しなければなりません。

void PyEval_SetProfile(Py_tracefunc func, PyObject *obj)

   プロファイル関数を *func* に設定します。 *obj* パラメタは関数の第一
   引数として渡されるもので、何らかの Python オブジェクトあるいは
   "NULL" です。 プロファイル関数がスレッド状態を維持する必要があるな
   ら、各々のスレッドに異なる *obj* を使うことで、状態を記憶しておく便
   利でスレッドセーフな場所を提供できます。 プロファイル関数は、モニタ
   されているイベントのうち、 "PyTrace_LINE" "PyTrace_OPCODE",
   "PyTrace_EXCEPTION" を除く全てのイベントに対して呼び出されます。

void PyEval_SetTrace(Py_tracefunc func, PyObject *obj)

   トレース関数を *func* に設定します。 この関数は
   "PyEval_SetProfile()" と同じですが、トレース関数は行番号イベントお
   よび opcode イベントを受け取り、呼び出された C 関数オブジェクトと関
   係する任意のイベントを受け取らないところが異なっています。
   "PyEval_SetTrace()" で登録されたトレース関数は、*what* 引数の値とし
   て "PyTrace_C_CALL", "PyTrace_C_EXCEPTION", "PyTrace_C_RETURN" を受
   け取りません。


高度なデバッガサポート (advanced debugger support)
==================================================

以下の関数は高度なデバッグツールでの使用のためだけのものです。

PyInterpreterState* PyInterpreterState_Head()

   インタプリタ状態オブジェクトからなるリストのうち、先頭にあるものを
   返します。

PyInterpreterState* PyInterpreterState_Main()

   メインインタプリタの状態オブジェクトを返します。

PyInterpreterState* PyInterpreterState_Next(PyInterpreterState *interp)

   インタプリタ状態オブジェクトからなるリストのうち、*interp* の次にあ
   るものを返します。

PyThreadState * PyInterpreterState_ThreadHead(PyInterpreterState *interp)

   インタプリタ *interp* に関連付けられているスレッドからなるリストの
   うち、先頭にある "PyThreadState" オブジェクトを返します。

PyThreadState* PyThreadState_Next(PyThreadState *tstate)

   *tstate* と同じ "PyInterpreterState" オブジェクトに属しているスレッ
   ド状態オブジェクトのうち、 *tstate* の次にあるものを返します。


スレッドローカルストレージのサポート
====================================

The Python interpreter provides low-level support for thread-local
storage (TLS) which wraps the underlying native TLS implementation to
support the Python-level thread local storage API ("threading.local").
The CPython C level APIs are similar to those offered by pthreads and
Windows: use a thread key and functions to associate a "void*" value
per thread.

API で使われる関数を呼ぶときは、 GIL を取得する必要は *ありません* 。
関数自身のロックがサポートされています。

"Python.h" は TLS API の宣言を include せず、スレッドローカルストレー
ジを使うには "pythread.h" を include する必要があることに注意してくだ
さい。

注釈:

  None of these API functions handle memory management on behalf of
  the "void*" values.  You need to allocate and deallocate them
  yourself. If the "void*" values happen to be "PyObject*", these
  functions don't do refcount operations on them either.


スレッド固有ストレージ (Thread Specific Storage, TSS) API
---------------------------------------------------------

TSS API は、 CPython インタプリタに含まれている既存の TLS API を置き換
えるために導入されました。 この API は、スレッドキーの表現に "int" の
代わりに新しい型 "Py_tss_t" を使います。

バージョン 3.7 で追加.

参考: "CPython のスレッドローカルストレージのための新しい C API" (**PEP
    539**)

Py_tss_t

   このデータ構造体はスレッドキーの状態を表現しています。この構造体の
   定義は、根底の TLS 実装に依存し、キーの初期化状態を表現する内部フィ
   ールドを持ちます。 この構造体には公開 (public) のメンバはありません
   。

   Py_LIMITED_API が定義されていないときは、この型の
   "Py_tss_NEEDS_INIT" による静的メモリ確保ができます。

Py_tss_NEEDS_INIT

   このマクロは "Py_tss_t" 変数の初期化子に展開されます。 このマクロは
   Py_LIMITED_API があるときは定義されません。


動的メモリ確保
~~~~~~~~~~~~~~

動的な "Py_tss_t" のメモリ確保は Py_LIMITED_API でビルドされた拡張モジ
ュールで必要になりますが、その実装がビルド時に不透明なために、この型の
静的なメモリ確保は不可能です。

Py_tss_t* PyThread_tss_alloc()

   Return a value which is the same state as a value initialized with
   "Py_tss_NEEDS_INIT", or "NULL" in the case of dynamic allocation
   failure.

void PyThread_tss_free(Py_tss_t *key)

   Free the given *key* allocated by "PyThread_tss_alloc()", after
   first calling "PyThread_tss_delete()" to ensure any associated
   thread locals have been unassigned. This is a no-op if the *key*
   argument is *NULL*.

   注釈:

     A freed key becomes a dangling pointer, you should reset the key
     to *NULL*.


メソッド
~~~~~~~~

The parameter *key* of these functions must not be "NULL".  Moreover,
the behaviors of "PyThread_tss_set()" and "PyThread_tss_get()" are
undefined if the given "Py_tss_t" has not been initialized by
"PyThread_tss_create()".

int PyThread_tss_is_created(Py_tss_t *key)

   Return a non-zero value if the given "Py_tss_t" has been
   initialized by "PyThread_tss_create()".

int PyThread_tss_create(Py_tss_t *key)

   Return a zero value on successful initialization of a TSS key.  The
   behavior is undefined if the value pointed to by the *key* argument
   is not initialized by "Py_tss_NEEDS_INIT".  This function can be
   called repeatedly on the same key -- calling it on an already
   initialized key is a no-op and immediately returns success.

void PyThread_tss_delete(Py_tss_t *key)

   Destroy a TSS key to forget the values associated with the key
   across all threads, and change the key's initialization state to
   uninitialized.  A destroyed key is able to be initialized again by
   "PyThread_tss_create()". This function can be called repeatedly on
   the same key -- calling it on an already destroyed key is a no-op.

int PyThread_tss_set(Py_tss_t *key, void *value)

   Return a zero value to indicate successfully associating a "void*"
   value with a TSS key in the current thread.  Each thread has a
   distinct mapping of the key to a "void*" value.

void* PyThread_tss_get(Py_tss_t *key)

   Return the "void*" value associated with a TSS key in the current
   thread.  This returns "NULL" if no value is associated with the key
   in the current thread.


スレッドローカルストレージ (TLS) API
------------------------------------

バージョン 3.7 で非推奨: This API is superseded by Thread Specific
Storage (TSS) API.

注釈:

  This version of the API does not support platforms where the native
  TLS key is defined in a way that cannot be safely cast to "int".  On
  such platforms, "PyThread_create_key()" will return immediately with
  a failure status, and the other TLS functions will all be no-ops on
  such platforms.

前述の互換性の問題により、このバージョンのAPIは新規のコードで利用すべ
きではありません。

int PyThread_create_key()

void PyThread_delete_key(int key)

int PyThread_set_key_value(int key, void *value)

void* PyThread_get_key_value(int key)

void PyThread_delete_key_value(int key)

void PyThread_ReInitTLS()
