Python初始化，终结和线程

在Python初始化之前¶

在一个植入了 Python 的应用程序中，Py_Initialize() 函数必须在任何其他 Python/C API 函数之前被调用；例外的只有个别函数和 全局配置变量。

在初始化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()

全局配置变量¶

Python 有负责控制全局配置中不同特性和选项的变量。这些标志默认被 命令行选项。

当一个选项设置一个旗标时，该旗标的值将是设置选项的次数。 例如，-b 会将 Py_BytesWarningFlag 设为 1 而 -bb 会将 Py_BytesWarningFlag 设为 2.

Py_BytesWarningFlag¶

Issue a warning when comparing bytes or bytearray with

str or bytes with int. Issue an error if greater

or equal to 2.

由 -b 选项设置。

Py_DebugFlag¶

Turn on parser debugging output (for expert only, depending on compilation

options).

Set by the -d option and the PYTHONDEBUG environment

variable.

Py_DontWriteBytecodeFlag¶

If set to non-zero, Python won't try to write .pyc files on the

import of source modules.

Set by the -B option and the PYTHONDONTWRITEBYTECODE

environment variable.

Py_FrozenFlag¶

Suppress error messages when calculating the module search path in

Py_GetPath().

Private flag used by _freeze_importlib and frozenmain programs.

Py_HashRandomizationFlag¶

Set to 1 if the PYTHONHASHSEED environment variable is set to

a non-empty string.

If the flag is non-zero, read the PYTHONHASHSEED environment

variable to initialize the secret hash seed.

Py_IgnoreEnvironmentFlag¶

忽略所有 PYTHON* 环境变量，例如可能已设置的 PYTHONPATH 和 PYTHONHOME。

由 -E 和 -I 选项设置。

Py_InspectFlag¶

When a script is passed as first argument or the -c option is used,

enter interactive mode after executing the script or the command, even when

sys.stdin does not appear to be a terminal.

Set by the -i option and the PYTHONINSPECT environment

variable.

Py_InteractiveFlag¶

由 -i 选项设置。

Py_IsolatedFlag¶

Run Python in isolated mode. In isolated mode sys.path contains

neither the script's directory nor the user's site-packages directory.

由 -I 选项设置。

3.4 新版功能.

Py_LegacyWindowsFSEncodingFlag¶

If the flag is non-zero, use the mbcs encoding instead of the UTF-8

encoding for the filesystem encoding.

Set to 1 if the PYTHONLEGACYWINDOWSFSENCODING environment

variable is set to a non-empty string.

有关更多详细信息，请参阅 PEP 529。

可用性: Windows。

Py_LegacyWindowsStdioFlag¶

If the flag is non-zero, use io.FileIO instead of

WindowsConsoleIO for sys standard streams.

Set to 1 if the PYTHONLEGACYWINDOWSSTDIO environment

variable is set to a non-empty string.

有关更多详细信息，请参阅 PEP 528。

可用性: Windows。

Py_NoSiteFlag¶

禁用 site 的导入及其所附带的基于站点对 sys.path 的操作。 如果 site 会在稍后被显式地导入也会禁用这些操作 (如果你希望触发它们则应调用 site.main())。

由 -S 选项设置。

Py_NoUserSiteDirectory¶

不要将 用户site-packages目录 添加到 sys.path。

Set by the -s and -I options, and the

PYTHONNOUSERSITE environment variable.

Py_OptimizeFlag¶

Set by the -O option and the PYTHONOPTIMIZE environment

variable.

Py_QuietFlag¶

即使在交互模式下也不显示版权和版本信息。

由 -q 选项设置。

3.2 新版功能.

Py_UnbufferedStdioFlag¶

Force the stdout and stderr streams to be unbuffered.

Set by the -u option and the PYTHONUNBUFFERED

environment variable.

Py_VerboseFlag¶

Print a message each time a module is initialized, showing the place

(filename or built-in module) from which it is loaded. If greater or equal

to 2, print a message for each file that is checked for when

searching for a module. Also provides information on module cleanup at exit.

Set by the -v option and the PYTHONVERBOSE environment

variable.

Initializing and finalizing the interpreter¶

void Py_Initialize()¶

Initialize the Python interpreter. In an application embedding Python,

this should be called before using any other Python/C API functions; see

Before Python Initialization for the few exceptions.

This initializes

the table of loaded modules (sys.modules), and creates the fundamental

modules builtins, __main__ and sys. It also initializes

the module search path (sys.path). It does not set sys.argv; use

PySys_SetArgvEx() for that. This is a no-op when called for a second time

(without calling Py_FinalizeEx() first). There is no return value; it is a

fatal error if the initialization fails.

注解

On Windows, changes the console mode from O_TEXT to O_BINARY, which will

also affect non-Python uses of the console using the C Runtime.

void Py_InitializeEx(int initsigs)¶

This function works like Py_Initialize() if initsigs is 1. If

initsigs is 0, it skips initialization registration of signal handlers, which

might be useful when Python is embedded.

int Py_IsInitialized()¶

Return true (nonzero) when the Python interpreter has been initialized, false

(zero) if not. After Py_FinalizeEx() is called, this returns false until

Py_Initialize() is called again.

int Py_FinalizeEx()¶

Undo all initializations made by Py_Initialize() and subsequent use of

Python/C API functions, and destroy all sub-interpreters (see

Py_NewInterpreter() below) that were created and not yet destroyed since

the last call to Py_Initialize(). Ideally, this frees all memory

allocated by the Python interpreter. This is a no-op when called for a second

time (without calling Py_Initialize() again first). Normally the

return value is 0. If there were errors during finalization

(flushing buffered data), -1 is returned.

This function is provided for a number of reasons. An embedding application

might want to restart Python without having to restart the application itself.

An application that has loaded the Python interpreter from a dynamically

loadable library (or DLL) might want to free all memory allocated by Python

before unloading the DLL. During a hunt for memory leaks in an application a

developer might want to free all memory allocated by Python before exiting from

the application.

Bugs and caveats: The destruction of modules and objects in modules is done

in random order; this may cause destructors (__del__() methods) to fail

when they depend on other objects (even functions) or modules. Dynamically

loaded extension modules loaded by Python are not unloaded. Small amounts of

memory allocated by the Python interpreter may not be freed (if you find a leak,

please report it). Memory tied up in circular references between objects is not

freed. Some memory allocated by extension modules may not be freed. Some

extensions may not work properly if their initialization routine is called more

than once; this can happen if an application calls Py_Initialize() and

Py_FinalizeEx() more than once.

3.6 新版功能.

void Py_Finalize()¶

This is a backwards-compatible version of Py_FinalizeEx() that

disregards the return value.

Process-wide parameters¶

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

This function should be called before Py_Initialize(), if it is

called at all. It specifies which encoding and error handling to use

with standard IO, with the same meanings as in str.encode().

It overrides PYTHONIOENCODING values, and allows embedding code

to control IO encoding when the environment variable does not work.

encoding and/or errors may be NULL to use

PYTHONIOENCODING and/or default values (depending on other

settings).

Note that sys.stderr always uses the "backslashreplace" error

handler, regardless of this (or any other) setting.

If Py_FinalizeEx() is called, this function will need to be called

again in order to affect subsequent calls to Py_Initialize().

Returns 0 if successful, a nonzero value on error (e.g. calling after the

interpreter has already been initialized).

3.4 新版功能.

void Py_SetProgramName(const wchar_t *name)¶

This function should be called before Py_Initialize() is called for

the first time, if it is called at all. It tells the interpreter the value

of the argv[0] argument to the main() function of the program

(converted to wide characters).

This is used by Py_GetPath() and some other functions below to find

the Python run-time libraries relative to the interpreter executable. The

default value is 'python'. The argument should point to a

zero-terminated wide character string in static storage whose contents will not

change for the duration of the program's execution. No code in the Python

interpreter will change the contents of this storage.

Use Py_DecodeLocale() to decode a bytes string to get a

wchar_* string.

wchar* Py_GetProgramName()¶

Return the program name set with Py_SetProgramName(), or the default.

The returned string points into static storage; the caller should not modify its

value.

wchar_t* Py_GetPrefix()¶

Return the prefix for installed platform-independent files. This is derived

through a number of complicated rules from the program name set with

Py_SetProgramName() and some environment variables; for example, if the

program name is '/usr/local/bin/python', the prefix is '/usr/local'. The

returned string points into static storage; the caller should not modify its

value. This corresponds to the prefix variable in the top-level

Makefile and the --prefix argument to the configure

script at build time. The value is available to Python code as sys.prefix.

It is only useful on Unix. See also the next function.

wchar_t* Py_GetExecPrefix()¶

Return the exec-prefix for installed platform-dependent files. This is

derived through a number of complicated rules from the program name set with

Py_SetProgramName() and some environment variables; for example, if the

program name is '/usr/local/bin/python', the exec-prefix is

'/usr/local'. The returned string points into static storage; the caller

should not modify its value. This corresponds to the exec_prefix

variable in the top-level Makefile and the --exec-prefix

argument to the configure script at build time. The value is

available to Python code as sys.exec_prefix. It is only useful on Unix.

Background: The exec-prefix differs from the prefix when platform dependent

files (such as executables and shared libraries) are installed in a different

directory tree. In a typical installation, platform dependent files may be

installed in the /usr/local/plat subtree while platform independent may

be installed in /usr/local.

Generally speaking, a platform is a combination of hardware and software

families, e.g. Sparc machines running the Solaris 2.x operating system are

considered the same platform, but Intel machines running Solaris 2.x are another

platform, and Intel machines running Linux are yet another platform. Different

major revisions of the same operating system generally also form different

platforms. Non-Unix operating systems are a different story; the installation

strategies on those systems are so different that the prefix and exec-prefix are

meaningless, and set to the empty string. Note that compiled Python bytecode

files are platform independent (but not independent from the Python version by

which they were compiled!).

System administrators will know how to configure the mount or

automount programs to share /usr/local between platforms

while having /usr/local/plat be a different filesystem for each

platform.

wchar_t* Py_GetProgramFullPath()¶

Return the full program name of the Python executable; this is computed as a

side-effect of deriving the default module search path from the program name

(set by Py_SetProgramName() above). The returned string points into

static storage; the caller should not modify its value. The value is available

to Python code as sys.executable.

wchar_t* Py_GetPath()¶

Return the default module search path; this is computed from the program name

(set by Py_SetProgramName() above) and some environment variables.

The returned string consists of a series of directory names separated by a

platform dependent delimiter character. The delimiter character is ':'

on Unix and Mac OS X, ';' on Windows. The returned string points into

static storage; the caller should not modify its value. The list

sys.path is initialized with this value on interpreter startup; it

can be (and usually is) modified later to change the search path for loading

modules.

void Py_SetPath(const wchar_t *)¶

Set the default module search path. If this function is called before

Py_Initialize(), then Py_GetPath() won't attempt to compute a

default search path but uses the one provided instead. This is useful if

Python is embedded by an application that has full knowledge of the location

of all modules. The path components should be separated by the platform

dependent delimiter character, which is ':' on Unix and Mac OS X, ';'

on Windows.

This also causes sys.executable to be set only to the raw program

name (see Py_SetProgramName()) 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().

Use Py_DecodeLocale() to decode a bytes string to get a

wchar_* string.

The path argument is copied internally, so the caller may free it after the

call completes.

const char* Py_GetVersion()¶

Return the version of this Python interpreter. This is a string that looks

something like

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

The first word (up to the first space character) is the current Python version;

the first three characters are the major and minor version separated by a

period. The returned string points into static storage; the caller should not

modify its value. The value is available to Python code as sys.version.

const char* Py_GetPlatform()¶

Return the platform identifier for the current platform. On Unix, this is

formed from the "official" name of the operating system, converted to lower

case, followed by the major revision number; e.g., for Solaris 2.x, which is

also known as SunOS 5.x, the value is 'sunos5'. On Mac OS X, it is

'darwin'. On Windows, it is 'win'. The returned string points into

static storage; the caller should not modify its value. The value is available

to Python code as sys.platform.

const char* Py_GetCopyright()¶

Return the official copyright string for the current Python version, for example

'Copyright1991-1995StichtingMathematischCentrum,Amsterdam'

The returned string points into static storage; the caller should not modify its

value. The value is available to Python code as sys.copyright.

const char* Py_GetCompiler()¶

Return an indication of the compiler used to build the current Python version,

in square brackets, for example:

"[GCC 2.7.2.2]"

The returned string points into static storage; the caller should not modify its

value. The value is available to Python code as part of the variable

sys.version.

const char* Py_GetBuildInfo()¶

Return information about the sequence number and build date and time of the

current Python interpreter instance, for example

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

The returned string points into static storage; the caller should not modify its

value. The value is available to Python code as part of the variable

sys.version.

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

Set sys.argv based on argc and argv. These parameters are

similar to those passed to the program's main() function with the

difference that the first entry should refer to the script file to be

executed rather than the executable hosting the Python interpreter. If there

isn't a script that will be run, the first entry in argv can be an empty

string. If this function fails to initialize sys.argv, a fatal

condition is signalled using Py_FatalError().

If updatepath is zero, this is all the function does. If updatepath

is non-zero, the function also modifies sys.path according to the

following algorithm:

• If the name of an existing script is passed in argv[0], the absolute

  path of the directory where the script is located is prepended to

  sys.path.

• Otherwise (that is, if argc is 0 or argv[0] doesn't point

  to an existing file name), an empty string is prepended to

  sys.path, which is the same as prepending the current working

  directory (".").

Use Py_DecodeLocale() to decode a bytes string to get a

wchar_* string.

注解

It is recommended that applications embedding the Python interpreter

for purposes other than executing a single script pass 0 as updatepath,

and update sys.path themselves if desired.

See CVE-2008-5983.

On versions before 3.1.3, you can achieve the same effect by manually

popping the first sys.path element after having called

PySys_SetArgv(), for example using:

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

3.1.3 新版功能.

void PySys_SetArgv(int argc, wchar_t **argv)¶

This function works like PySys_SetArgvEx() with updatepath set

to 1 unless the python interpreter was started with the

-I.

Use Py_DecodeLocale() to decode a bytes string to get a

wchar_* string.

在 3.4 版更改: The updatepath value depends on -I.

void Py_SetPythonHome(const wchar_t *home)¶

Set the default "home" directory, that is, the location of the standard

Python libraries. See PYTHONHOME for the meaning of the

argument string.

The argument should point to a zero-terminated character string in static

storage whose contents will not change for the duration of the program's

execution. No code in the Python interpreter will change the contents of

this storage.

Use Py_DecodeLocale() to decode a bytes string to get a

wchar_* string.

w_char* Py_GetPythonHome()¶

Return the default "home", that is, the value set by a previous call to

Py_SetPythonHome(), or the value of the PYTHONHOME

environment variable if it is set.

Thread State and the Global Interpreter Lock¶

The Python interpreter is not fully thread-safe. In order to support

multi-threaded Python programs, there's a global lock, called the global

interpreter lock or GIL, that must be held by the current thread before

it can safely access Python objects. Without the lock, even the simplest

operations could cause problems in a multi-threaded program: for example, when

two threads simultaneously increment the reference count of the same object, the

reference count could end up being incremented only once instead of twice.

Therefore, the rule exists that only the thread that has acquired the

GIL may operate on Python objects or call Python/C API functions.

In order to emulate concurrency of execution, the interpreter regularly

tries to switch threads (see sys.setswitchinterval()). The lock is also

released around potentially blocking I/O operations like reading or writing

a file, so that other Python threads can run in the meantime.

The Python interpreter keeps some thread-specific bookkeeping information

inside a data structure called PyThreadState. There's also one

global variable pointing to the current PyThreadState: it can

be retrieved using PyThreadState_Get().

Savethethreadstateinalocalvariable.
Releasetheglobalinterpreterlock.
...DosomeblockingI/Ooperation...
Reacquiretheglobalinterpreterlock.
Restorethethreadstatefromthelocalvariable.

Py_BEGIN_ALLOW_THREADS
...DosomeblockingI/Ooperation...
Py_END_ALLOW_THREADS

PyThreadState*_save;
_save=PyEval_SaveThread();
...DosomeblockingI/Ooperation...
PyEval_RestoreThread(_save);

PyGILState_STATEgstate;
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);

Sub-interpreter support¶

While in most uses, you will only embed a single Python interpreter, there

are cases where you need to create several independent interpreters in the

same process and perhaps even in the same thread. Sub-interpreters allow

you to do that. You can switch between sub-interpreters using the

PyThreadState_Swap() function. You can create and destroy them

using the following functions:

PyThreadState* Py_NewInterpreter()¶

Create a new sub-interpreter. This is an (almost) totally separate environment

for the execution of Python code. In particular, the new interpreter has

separate, independent versions of all imported modules, including the

fundamental modules builtins, __main__ and sys. The

table of loaded modules (sys.modules) and the module search path

(sys.path) are also separate. The new environment has no sys.argv

variable. It has new standard I/O stream file objects sys.stdin,

sys.stdout and sys.stderr (however these refer to the same underlying

file descriptors).

The return value points to the first thread state created in the new

sub-interpreter. This thread state is made in the current thread state.

Note that no actual thread is created; see the discussion of thread states

below. If creation of the new interpreter is unsuccessful, NULL is

returned; no exception is set since the exception state is stored in the

current thread state and there may not be a current thread state. (Like all

other Python/C API functions, the global interpreter lock must be held before

calling this function and is still held when it returns; however, unlike most

other Python/C API functions, there needn't be a current thread state on

entry.)

Extension modules are shared between (sub-)interpreters as follows: 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. 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.

void Py_EndInterpreter(PyThreadState *tstate)¶

Destroy the (sub-)interpreter represented by the given thread state. The given

thread state must be the current thread state. See the discussion of thread

states below. When the call returns, the current thread state is NULL. All

thread states associated with this interpreter are destroyed. (The global

interpreter lock must be held before calling this function and is still held

when it returns.) Py_FinalizeEx() will destroy all sub-interpreters that

haven't been explicitly destroyed at that point.

异步通知¶

A mechanism is provided to make asynchronous notifications to the main

interpreter thread. These notifications take the form of a function

pointer and a void pointer argument.

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

Schedule a function to be called from the main interpreter thread. On

success, 0 is returned and func is queued for being called in the

main thread. On failure, -1 is returned without setting any exception.

When successfully queued, func will be eventually called from the

main interpreter thread with the argument arg. It will be called

asynchronously with respect to normally running Python code, but with

both these conditions met:

• on a bytecode boundary;

• with the main thread holding the global interpreter lock

  (func can therefore use the full C API).

func must return 0 on success, or -1 on failure with an exception

set. func won't be interrupted to perform another asynchronous

notification recursively, but it can still be interrupted to switch

threads if the global interpreter lock is released.

This function doesn't need a current thread state to run, and it doesn't

need the global interpreter lock.

警告

This is a low-level function, only useful for very special cases.

There is no guarantee that func will be called as quick as

possible. If the main thread is busy executing a system call,

func won't be called before the system call returns. This

function is generally not suitable for calling Python code from

arbitrary C threads. Instead, use the PyGILState API.

3.1 新版功能.

分析和跟踪¶

The Python interpreter provides some low-level support for attaching profiling

and execution tracing facilities. These are used for profiling, debugging, and

coverage analysis tools.

This C interface allows the profiling or tracing code to avoid the overhead of

calling through Python-level callable objects, making a direct C function call

instead. The essential attributes of the facility have not changed; the

interface allows trace functions to be installed per-thread, and the basic

events reported to the trace function are the same as had been reported to the

Python-level trace functions in previous versions.

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

The type of the trace function registered using PyEval_SetProfile() and

PyEval_SetTrace(). The first parameter is the object passed to the

registration function as obj, frame is the frame object to which the event

pertains, what is one of the constants PyTrace_CALL,

PyTrace_EXCEPTION, PyTrace_LINE, PyTrace_RETURN,

PyTrace_C_CALL, PyTrace_C_EXCEPTION, PyTrace_C_RETURN,

or PyTrace_OPCODE, and arg depends on the value of what:

what 的值	arg 的含义
PyTrace_CALL	总是 Py_None.
PyTrace_EXCEPTION	sys.exc_info() 返回的异常信息。
PyTrace_LINE	总是 Py_None.
PyTrace_RETURN	Value being returned to the caller, or NULL if caused by an exception.
PyTrace_C_CALL	正在调用函数对象。
PyTrace_C_EXCEPTION	正在调用函数对象。
PyTrace_C_RETURN	正在调用函数对象。
PyTrace_OPCODE	总是 Py_None.

int PyTrace_CALL¶

The value of the what parameter to a Py_tracefunc function when a new

call to a function or method is being reported, or a new entry into a generator.

Note that the creation of the iterator for a generator function is not reported

as there is no control transfer to the Python bytecode in the corresponding

frame.

int PyTrace_EXCEPTION¶

The value of the what parameter to a Py_tracefunc function when an

exception has been raised. The callback function is called with this value for

what when after any bytecode is processed after which the exception becomes

set within the frame being executed. The effect of this is that as exception

propagation causes the Python stack to unwind, the callback is called upon

return to each frame as the exception propagates. Only trace functions receives

these events; they are not needed by the profiler.

int PyTrace_LINE¶

The value passed as the what parameter to a Py_tracefunc function

(but not a profiling function) when a line-number event is being reported.

It may be disabled for a frame by setting f_trace_lines to 0 on that frame.

int PyTrace_RETURN¶

The value for the what parameter to Py_tracefunc functions when a

call is about to return.

int PyTrace_C_CALL¶

The value for the what parameter to Py_tracefunc functions when a C

function is about to be called.

int PyTrace_C_EXCEPTION¶

The value for the what parameter to Py_tracefunc functions when a C

function has raised an exception.

int PyTrace_C_RETURN¶

The value for the what parameter to Py_tracefunc functions when a C

function has returned.

int PyTrace_OPCODE¶

The value for the what parameter to Py_tracefunc functions (but not

profiling functions) when a new opcode is about to be executed. This event is

not emitted by default: it must be explicitly requested by setting

f_trace_opcodes to 1 on the frame.

void PyEval_SetProfile(Py_tracefunc func, PyObject *obj)¶

Set the profiler function to func. The obj parameter is passed to the

function as its first parameter, and may be any Python object, or NULL. If

the profile function needs to maintain state, using a different value for obj

for each thread provides a convenient and thread-safe place to store it. The

profile function is called for all monitored events except PyTrace_LINE

PyTrace_OPCODE and PyTrace_EXCEPTION.

void PyEval_SetTrace(Py_tracefunc func, PyObject *obj)¶

Set the tracing function to func. This is similar to

PyEval_SetProfile(), except the tracing function does receive line-number

events and per-opcode events, but does not receive any event related to C function

objects being called. Any trace function registered using PyEval_SetTrace()

will not receive PyTrace_C_CALL, PyTrace_C_EXCEPTION or

PyTrace_C_RETURN as a value for the what parameter.

高级调试器支持¶

These functions are only intended to be used by advanced debugging tools.

PyInterpreterState* PyInterpreterState_Head()¶

Return the interpreter state object at the head of the list of all such objects.

PyInterpreterState* PyInterpreterState_Main()¶

Return the main interpreter state object.

PyInterpreterState* PyInterpreterState_Next(PyInterpreterState *interp)¶

Return the next interpreter state object after interp from the list of all

such objects.

PyThreadState * PyInterpreterState_ThreadHead(PyInterpreterState *interp)¶

Return the pointer to the first PyThreadState object in the list of

threads associated with the interpreter interp.

PyThreadState* PyThreadState_Next(PyThreadState *tstate)¶

Return the next thread state object after tstate from the list of all such

objects belonging to the same PyInterpreterState object.

Thread Local Storage Support¶

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.

The GIL does not need to be held when calling these functions; they supply

their own locking.

Note that Python.h does not include the declaration of the TLS APIs,

you need to include pythread.h to use thread-local storage.