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


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
に設定され、 "-b" では "Py_BytesWarningFlag" が 2 に設定されます。

Py_BytesWarningFlag

   "bytes" または "bytearray" を "str" と比較した場合、または、
   "bytes" を "int" と比較した場合に警告を発生させます。 値が "2" 以上
   になった場合は、エラーを発生させます。

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

Py_DebugFlag

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

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

Py_DontWriteBytecodeFlag

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

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

Py_FrozenFlag

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

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

Py_HashRandomizationFlag

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

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

Py_IgnoreEnvironmentFlag

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

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

Py_InspectFlag

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

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

Py_InteractiveFlag

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

Py_IsolatedFlag

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

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

   バージョン 3.4 で追加.

Py_LegacyWindowsFSEncodingFlag

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

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

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

   利用可能な環境: Windows 。

Py_LegacyWindowsStdioFlag

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

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

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

   利用可能な環境: Windows 。

Py_NoSiteFlag

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

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

Py_NoUserSiteDirectory

   "user site-packages directory" を "sys.path" に追加しません。

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

Py_OptimizeFlag

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

Py_QuietFlag

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

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

   バージョン 3.2 で追加.

Py_UnbufferedStdioFlag

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

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

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 度以上呼び出すと起こり得ます。

   バージョン 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 では "';'" です。

   また、この関数は "sys.executable" に特に加工されていないプログラム
   名 ("Py_SetProgramName()" を参照) をセットし、 "sys.prefix" と
   "sys.exec_prefix" に空文字列をセットします。 "Py_Initialize()" が呼
   び出された後で、これらの値を変更する必要がある場合は、呼び出し側の
   責任で行います。

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

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

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 を混ぜて使うことはサポートされていません。

注意しないといけないもう一つの重要な点は、 C の "fork()" を呼び出した
時の動作です。ほとんどの "fork()" を持っているシステムでは、fork され
たプロセスには fork を実行したスレッドしか存在しません。これは、別のス
レッドに取得されたロックがずっと解放されないことを意味します。 Python
は fork する前にロックを取得し、その後に fork を解放することでこの
"os.fork()" の問題を解決しています。加えて、子プロセスではすべての
Lock オブジェクト をリセットします。 Python を拡張したり埋め込んだりし
ている場合、 Python に fork 前に取得したり fork 後に解放しなければなら
ない追加の (Python 以外の) ロックを Python に教える手段がありません。
Python と同じことを実現するには、 "pthread_atfork()" のようなOSの機能
を使う必要があります。加えて、Python を拡張したり埋め込んだりしている
ときに、 "os.fork()" を通してではなく直接 "fork()" を呼び出すと、fork
後に失われるスレッドに取得されていた Python の内部ロックのためにデッド
ロックが発生するかもしれません。 "PyOS_AfterFork_Child()" は必要なロッ
クのリセットを試みますが、いつでもそれが可能とは限りません。


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

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

PyInterpreterState

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

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

PyThreadState

   単一のスレッドの状態を表現する表現するデータ構造体です。スレッドの
   インタプリタ状態を指すポインタ "PyInterpreterState *" "interp" だけ
   が公開されているデータメンバです。

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()

   Release the global interpreter lock (if it has been created and
   thread support is enabled) and reset the thread state to "NULL",
   returning the previous thread state (which is not "NULL").  If the
   lock has been created, the current thread must have acquired it.

void PyEval_RestoreThread(PyThreadState *tstate)

   Acquire the global interpreter lock (if it has been created and
   thread support is enabled) and set the thread state to *tstate*,
   which must not be "NULL".  If the lock has been created, the
   current thread must not have acquired it, otherwise deadlock
   ensues.

   注釈:

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

PyThreadState* PyThreadState_Get()

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

PyThreadState* PyThreadState_Swap(PyThreadState *tstate)

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

void PyEval_ReInitThreads()

   この関数は "PyOS_AfterFork_Child()" から呼び出され、新しい子プロセ
   スが、子プロセス内で実行していないスレッドが持っているロックを持た
   ないようにします。

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

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 を保持しておく
   必要はありませんが、この関数を次々に呼び出す必要がある場合には保持
   しておいたほうがよいでしょう。

void PyInterpreterState_Clear(PyInterpreterState *interp)

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

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* 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" であってはなりません。ロックはあらかじめ作成されていなけ
   ればなりません。この関数を呼び出したスレッドがすでにロックを獲得し
   ている場合、デッドロックに陥ります。

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

void PyEval_ReleaseThread(PyThreadState *tstate)

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

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

void PyEval_AcquireLock()

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

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

void PyEval_ReleaseLock()

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

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


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

ほとんどの場合は埋め込む Python インタプリタは1つだけですが、いくつか
の場合に同一プロセス内、あるいは同一スレッド内で、複数の独立したインタ
プリタを作成する必要があります。サブインタプリタはこれを可能にします。
"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 関数とは違い、関数から戻ったときの現在のスレッド状態が
   関数に入るときと同じとは限らないので注意してください。)

   拡張モジュールは以下のような形で (サブ) インタプリタ間で共有されま
   す: ある特定の拡張モジュールを最初に import すると、モジュールを通
   常通りに初期化し、そのモジュールの辞書の (浅い) コピーをしまい込ん
   でおきます。他の (サブ) インタプリタが同じ拡張モジュールを import
   すると、新たなモジュールを初期化し、先ほどのコピーの内容で辞書の値
   を埋めます; 拡張モジュールの "init" 関数は呼び出されません。この挙
   動は、 "Py_FinalizeEx()" および "Py_Initialize()" を呼び出してイン
   タプリタを完全に再初期化した後に拡張モジュールを import した際の挙
   動とは異なるので注意してください; 再初期化後に import を行うと、拡
   張モジュールの "initmodule" は再度 *呼び出されます* 。

void Py_EndInterpreter(PyThreadState *tstate)

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


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

サブインタプリタ (とメインインタプリタ) は同じプロセスの一部分なので、
インタプリタ間の隔離は完璧ではありません --- 例えば、 "os.close()" の
ような低レベルのファイル操作を使うと、 (偶然なり故意なりに) 互いのイン
タプリタ下にある開かれたファイルに影響を及ぼせてしまいます。拡張モジュ
ールを (サブ) インタプリタ間で共有する方法のせいで、拡張モジュールによ
っては正しく動作しないかもしれません; 拡張モジュールが (静的な) グロー
バル変数を利用している場合や、拡張モジュールが初期化後に自身のモジュー
ル辞書を操作する場合には特にそうです。一つのサブインタプリタで生成され
たオブジェクトは他のサブインタプリタの名前空間への挿入が可能です; ユー
ザ定義関数、メソッド、インスタンスおよびクラスをサブインタプリタをサブ
インタプリタ間で共有しないように十分注意してください。というのは、これ
らの共有オブジェクトが実行した import 文は間違った (サブ) インタプリタ
のロード済みモジュール辞書に影響を及ぼす場合があるからです。

サブインタプリタを "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* の次にあるものを返します。


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

Python インタプリタは、スレッドローカルストレージ (thread-local
storage, TLS) の低レベルサポートを提供していて、ネイティブの TLS 実装
を内部にラップして Python レベルのスレッドローカルストレージ API
("threading.local") をサポートしています。 CPython の C レベル API は
pthreads や Windows で与えられる TLS と同様です: スレッドキーとスレッ
ドごとに "void*" 値を関係付ける関数を使います。

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

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

注釈:

  この API 関数はどれも "void*" 値の代わりにメモリ管理を行うことはしま
  せん。 メモリの確保と解放は自前で行う必要があります。 "void*" 値がた
  またま "PyObject*" だった場合は、 API 関数はそれぞれの値の参照カウン
  トの操作は行いません。


スレッド固有ストレージ (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()
