Unless on a
of
, the Python interpreter is generally not thread-safe. In order to support multi-threaded Python programs, there’s a global lock, called the
or
, that must be held by a thread before accessing 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.
As such, only a thread that holds the GIL may operate on Python objects or invoke Python’s C API.
In order to emulate concurrency, the interpreter regularly tries to switch threads between bytecode instructions (see
). This is why locks are also necessary for thread-safety in pure-Python code.
Additionally, the global interpreter lock is released around blocking I/O operations, such as reading or writing to a file. From the C API, this is done by
.
The Python interpreter keeps some thread-local information inside a data structure called
, known as a
. Each thread has a thread-local pointer to a PyThreadState; a thread state referenced by this pointer is considered to be
.
A thread can only have one
at a time. An attached thread state is typically analogous with holding the GIL, except on free-threaded builds. On builds with the GIL enabled, attaching a thread state will block until the GIL can be acquired. However, even on builds with the GIL disabled, it is still required to have an attached thread state, as the interpreter needs to keep track of which threads may access Python objects.
Note
Even on the free-threaded build, attaching a thread state may block, as the GIL can be re-enabled or threads might be temporarily suspended (such as during a garbage collection).
Generally, there will always be an attached thread state when using Python’s C API, including during embedding and when implementing methods, so it’s uncommon to need to set up a thread state on your own. Only in some specific cases, such as in a
block or in a fresh thread, will the thread not have an attached thread state. If uncertain, check if
returns NULL.
If it turns out that you do need to create a thread state, call
followed by
, or use the dangerous
function.
Detaching the thread state from extension code
Most extension code manipulating the
has the following simple structure:
Savethethreadstateinalocalvariable....DosomeblockingI/Ooperation...Restorethethreadstatefromthelocalvariable.This is so common that a pair of macros exists to simplify it:
Py_BEGIN_ALLOW_THREADS...DosomeblockingI/Ooperation...Py_END_ALLOW_THREADSThe
macro opens a new block and declares a hidden local variable; the
macro closes the block.
The block above expands to the following code:
PyThreadState*_save;_save=PyEval_SaveThread();...DosomeblockingI/Ooperation...PyEval_RestoreThread(_save);Here is how these functions work:
The attached thread state implies that the GIL is held for the interpreter. To detach it,
is called and the result is stored in a local variable.
By detaching the thread state, the GIL is released, which allows other threads to attach to the interpreter and execute while the current thread performs blocking I/O. When the I/O operation is complete, the old thread state is reattached by calling
, which will wait until the GIL can be acquired.
Note
Performing blocking I/O is the most common use case for detaching the thread state, but it is also useful to call it over long-running native code that doesn’t need access to Python objects or Python’s C API. For example, the standard
and
modules detach the
when compressing or hashing data.
On a
, the
is usually out of the question, but detaching the thread state is still required, because the interpreter periodically needs to block all threads to get a consistent view of Python objects without the risk of race conditions. For example, CPython currently suspends all threads for a short period of time while running the garbage collector.
APIs
The following macros are normally used without a trailing semicolon; look for example usage in the Python source distribution.
Py_BEGIN_ALLOW_THREADS
Part of the
.This macro expands to {PyThreadState*_save;_save=PyEval_SaveThread();. Note that it contains an opening brace; it must be matched with a following
macro. See above for further discussion of this macro.
Py_END_ALLOW_THREADS
Part of the
.This macro expands to PyEval_RestoreThread(_save);}. Note that it contains a closing brace; it must be matched with an earlier
macro. See above for further discussion of this macro.
Py_BLOCK_THREADS
Part of the
.This macro expands to PyEval_RestoreThread(_save);: it is equivalent to
without the closing brace.
Py_UNBLOCK_THREADS
Part of the
.This macro expands to _save=PyEval_SaveThread();: it is equivalent to
without the opening brace and variable declaration.
Non-Python created threads
When threads are created using the dedicated Python APIs (such as the
module), a thread state is automatically associated with them, However, when a thread is created from native code (for example, by a third-party library with its own thread management), it doesn’t hold an attached thread state.
If you need to call Python code from these threads (often this will be part of a callback API provided by the aforementioned third-party library), you must first register these threads with the interpreter by creating a new thread state and attaching it.
The most robust way to do this is through
followed by
.
Note
PyThreadState_New requires an argument pointing to the desired interpreter; such a pointer can be acquired via a call to
from the code where the thread was created.
For example:
/* The return value of PyInterpreterState_Get() from the function that created this thread. */PyInterpreterState*interp=thread_data->interp;/* Create a new thread state for the interpreter. It does not start out attached. */PyThreadState*tstate=PyThreadState_New(interp);/* Attach the thread state, which will acquire the GIL. */PyThreadState_Swap(tstate);/* Perform Python actions here. */result=CallSomeFunction();/* evaluate result or handle exception *//* Destroy the thread state. No Python API allowed beyond this point. */PyThreadState_Clear(tstate);PyThreadState_DeleteCurrent();Warning
If the interpreter finalized before PyThreadState_Swap was called, then interp will be a dangling pointer!
Legacy API
Another common pattern to call Python code from a non-Python thread is to use
followed by a call to
.
These functions do not work well when multiple interpreters exist in the Python process. If no Python interpreter has ever been used in the current thread (which is common for threads created outside Python), PyGILState_Ensure will create and attach a thread state for the “main” interpreter (the first interpreter in the Python process).
Additionally, these functions have thread-safety issues during interpreter finalization. Using PyGILState_Ensure during finalization will likely crash the process.
Usage of these functions look like such:
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);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
by acquiring the locks it uses internally before the fork, and releasing them afterwards. In addition, it resets any
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.
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
does. This means finalizing all other
objects belonging to the current interpreter and all other
objects. Due to this and the special nature of the
, 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.
High-level APIs
These are the most commonly used types and functions when writing multi-threaded C extensions.
typePyThreadState
Part of the
(as an opaque struct).This data structure represents the state of a single thread. The only public data member is:
*interp
This thread’s interpreter state.
voidPyEval_InitThreads()
Part of the
.Deprecated function which does nothing.
In Python 3.6 and older, this function created the GIL if it didn’t exist.
Changed in version 3.9: The function now does nothing.
Changed in version 3.7: This function is now called by
, so you don’t have to call it yourself anymore.
Changed in version 3.2: This function cannot be called before
anymore.
Deprecated since version 3.9.
*PyEval_SaveThread()
Part of the
.Detach the
and return it. The thread will have no
upon returning.
voidPyEval_RestoreThread(
*tstate)
Part of the
.Set the
to tstate. The passed
should not be attached, otherwise deadlock ensues. tstate will be attached upon returning.
Note
Calling this function from a thread when the runtime is finalizing will hang the thread until the program exits, even if the thread was not created by Python. Refer to
Cautions regarding runtime finalization
for more details.
Changed in version 3.14: Hangs the current thread, rather than terminating it, if called while the interpreter is finalizing.
*PyThreadState_Get()
Part of the
.Return the
. If the thread has no attached thread state, (such as when inside of
block), then this issues a fatal error (so that the caller needn’t check for NULL).
See also
.
*PyThreadState_GetUnchecked()
Similar to
, but don’t kill the process with a fatal error if it is NULL. The caller is responsible to check if the result is NULL.
Added in version 3.13: In Python 3.5 to 3.12, the function was private and known as _PyThreadState_UncheckedGet().
*PyThreadState_Swap(
*tstate)
Part of the
.Set the
to tstate, and return the
that was attached prior to calling.
This function is safe to call without an
; it will simply return NULL indicating that there was no prior thread state.
Note
Similar to
, this function will hang the thread if the runtime is finalizing.
GIL-state APIs
The following functions use thread-local storage, and are not compatible with sub-interpreters:
typePyGILState_STATE
Part of the
.The type of the value returned by
and passed to
.
enumeratorPyGILState_LOCKED
The GIL was already held when
was called.
enumeratorPyGILState_UNLOCKED
The GIL was not held when
was called.
PyGILState_Ensure()
Part of the
.Ensure that the current thread is ready to call the Python C API regardless of the current state of Python, or of the
. This may be called as many times as desired by a thread as long as each call is matched with a call to
. In general, other thread-related APIs may be used between
and PyGILState_Release() calls as long as the thread state is restored to its previous state before the Release(). For example, normal usage of the
and
macros is acceptable.
The return value is an opaque “handle” to the
when
was called, and must be passed to
to ensure Python is left in the same state. Even though recursive calls are allowed, these handles cannot be shared - each unique call to PyGILState_Ensure() must save the handle for its call to PyGILState_Release().
When the function returns, there will be an
and the thread will be able to call arbitrary Python code. Failure is a fatal error.
Warning
Calling this function when the runtime is finalizing is unsafe. Doing so will either hang the thread until the program ends, or fully crash the interpreter in rare cases. Refer to
Cautions regarding runtime finalization
for more details.
Changed in version 3.14: Hangs the current thread, rather than terminating it, if called while the interpreter is finalizing.
voidPyGILState_Release(
)
Part of the
.Release any resources previously acquired. After this call, Python’s state will be the same as it was prior to the corresponding
call (but generally this state will be unknown to the caller, hence the use of the GILState API).
Every call to
must be matched by a call to
on the same thread.
*PyGILState_GetThisThreadState()
Part of the
.Get the
for this thread. May return NULL if no GILState API has been used on the current thread. Note that the main thread always has such a thread-state, even if no auto-thread-state call has been made on the main thread. This is mainly a helper/diagnostic function.
Note
This function may return non-NULL even when the
is detached. Prefer
or
for most cases.
intPyGILState_Check()
Return 1 if the current thread is holding the
and 0 otherwise. This function can be called from any thread at any time. Only if it has had its
initialized via
will it return 1. This is mainly a helper/diagnostic function. It can be useful for example in callback contexts or memory allocation functions when knowing that the GIL is locked can allow the caller to perform sensitive actions or otherwise behave differently.
Note
If the current Python process has ever created a subinterpreter, this function will always return 1. Prefer
for most cases.
Added in version 3.4.
Low-level APIs
*PyThreadState_New(
*interp)
Part of the
.Create a new thread state object belonging to the given interpreter object. An
is not needed.
voidPyThreadState_Clear(
*tstate)
Part of the
.Reset all information in a
object. tstate must be
Changed in version 3.9: This function now calls the PyThreadState.on_delete callback. Previously, that happened in
.
Changed in version 3.13: The PyThreadState.on_delete callback was removed.
voidPyThreadState_Delete(
*tstate)
Part of the
.Destroy a
object. tstate should not be
to any thread. tstate must have been reset with a previous call to
.
voidPyThreadState_DeleteCurrent(void)
Detach the
(which must have been reset with a previous call to
) and then destroy it.
No
will be
upon returning.
*PyThreadState_GetFrame(
*tstate)
Part of the
since version 3.10.Get the current frame of the Python thread state tstate.
Return a
. Return NULL if no frame is currently executing.
See also
.
tstate must not be NULL, and must be
.
Added in version 3.9.
uint64_tPyThreadState_GetID(
*tstate)
Part of the
since version 3.10.Get the unique
identifier of the Python thread state tstate.
tstate must not be NULL, and must be
.
Added in version 3.9.
*PyThreadState_GetInterpreter(
*tstate)
Part of the
since version 3.10.Get the interpreter of the Python thread state tstate.
tstate must not be NULL, and must be
.
Added in version 3.9.
voidPyThreadState_EnterTracing(
*tstate)
Suspend tracing and profiling in the Python thread state tstate.
Resume them using the
function.
Added in version 3.11.
voidPyThreadState_LeaveTracing(
*tstate)
Resume tracing and profiling in the Python thread state tstate suspended by the
function.
See also
and
functions.
Added in version 3.11.
intPyUnstable_ThreadState_SetStackProtection(
*tstate, void*stack_start_addr, size_tstack_size)
This is
. It may change without warning in minor releases.
Set the stack protection start address and stack protection size of a Python thread state.
On success, return 0. On failure, set an exception and return -1.
CPython implements
for C code by raising
when it notices that the machine execution stack is close to overflow. See for example the
function. For this, it needs to know the location of the current thread’s stack, which it normally gets from the operating system. When the stack is changed, for example using context switching techniques like the Boost library’s boost::context, you must call
PyUnstable_ThreadState_SetStackProtection()
to inform CPython of the change.
Call
PyUnstable_ThreadState_SetStackProtection()
either before or after changing the stack. Do not call any other Python C API between the call and the stack change.
See
PyUnstable_ThreadState_ResetStackProtection()
for undoing this operation.
Added in version 3.15.
voidPyUnstable_ThreadState_ResetStackProtection(
*tstate)
This is
. It may change without warning in minor releases.
Reset the stack protection start address and stack protection size of a Python thread state to the operating system defaults.
See
PyUnstable_ThreadState_SetStackProtection()
for an explanation.
Added in version 3.15.
*PyThreadState_GetDict()
Return value: Borrowed reference. Part of the
.Return a dictionary in which extensions can store thread-specific state information. Each extension should use a unique key to use to store state in the dictionary. It is okay to call this function when no
is
. If this function returns NULL, no exception has been raised and the caller should assume no thread state is attached.
voidPyEval_AcquireThread(
*tstate)
Part of the
.
tstate to the current thread, which must not be NULL or already attached.
The calling thread must not already have an
.
Note
Calling this function from a thread when the runtime is finalizing will hang the thread until the program exits, even if the thread was not created by Python. Refer to
Cautions regarding runtime finalization
for more details.
Changed in version 3.8: Updated to be consistent with
,
, and
, and terminate the current thread if called while the interpreter is finalizing.
Changed in version 3.14: Hangs the current thread, rather than terminating it, if called while the interpreter is finalizing.
is a higher-level function which is always available (even when threads have not been initialized).
voidPyEval_ReleaseThread(
*tstate)
Part of the
.Detach the
. The tstate argument, which must not be NULL, is only used to check that it represents the attached thread state — if it isn’t, a fatal error is reported.
is a higher-level function which is always available (even when threads have not been initialized).
Asynchronous notifications
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.
intPy_AddPendingCall(int(*func)(void*), void*arg)
Part of the
.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
boundary;
with the main thread holding an
(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
is detached.
This function doesn’t need an
. However, to call this function in a subinterpreter, the caller must have an attached thread state. Otherwise, the function func can be scheduled to be called from the wrong interpreter.
Warning
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
.
Added in version 3.1.
Changed in version 3.9: If this function is called in a subinterpreter, the function func is now scheduled to be called from the subinterpreter, rather than being called from the main interpreter. Each subinterpreter now has its own list of scheduled calls.
Changed in version 3.12: This function now always schedules func to be run in the main interpreter.
intPy_MakePendingCalls(void)
Part of the
.Execute all pending calls. This is usually executed automatically by the interpreter.
This function returns 0 on success, and returns -1 with an exception set on failure.
If this is not called in the main thread of the main interpreter, this function does nothing and returns 0. The caller must hold an
.
Added in version 3.1.
Changed in version 3.12: This function only runs pending calls in the main interpreter.
intPyThreadState_SetAsyncExc(unsignedlongid,
*exc)
Part of the
.Asynchronously raise an exception in a thread. The id argument is the thread id of the target thread; exc is the exception object to be raised. This function does not
any references to exc. To prevent naive misuse, you must write your own C extension to call this. Must be called with an
. Returns the number of thread states modified; this is normally one, but will be zero if the thread id isn’t found. If exc is NULL, the pending exception (if any) for the thread is cleared. This raises no exceptions.
Changed in version 3.7: The type of the id parameter changed from long to unsignedlong.
Operating system thread APIs
PYTHREAD_INVALID_THREAD_ID
Sentinel value for an invalid thread ID.
This is currently equivalent to (unsignedlong)-1.
unsignedlongPyThread_start_new_thread(void(*func)(void*), void*arg)
Part of the
.Start function func in a new thread with argument arg. The resulting thread is not intended to be joined.
func must not be NULL, but arg may be NULL.
On success, this function returns the identifier of the new thread; on failure, this returns
.
The caller does not need to hold an
.
unsignedlongPyThread_get_thread_ident(void)
Part of the
.Return the identifier of the current thread, which will never be zero.
This function cannot fail, and the caller does not need to hold an
.
*PyThread_GetInfo(void)
Part of the
since version 3.3.Get general information about the current thread in the form of a
object. This information is accessible as
in Python.
On success, this returns a new
to the thread information; on failure, this returns NULL with an exception set.
The caller must hold an
.
PY_HAVE_THREAD_NATIVE_ID
This macro is defined when the system supports native thread IDs.
unsignedlongPyThread_get_thread_native_id(void)
Part of the
on platforms with native thread IDs.Get the native identifier of the current thread as it was assigned by the operating system’s kernel, which will never be less than zero.
This function is only available when
is defined.
This function cannot fail, and the caller does not need to hold an
.
voidPyThread_exit_thread(void)
Part of the
.Terminate the current thread. This function is generally considered unsafe and should be avoided. It is kept solely for backwards compatibility.
This function is only safe to call if all functions in the full call stack are written to safely allow it.
Warning
If the current system uses POSIX threads (also known as “pthreads”), this calls
, which attempts to unwind the stack and call C++ destructors on some libc implementations. However, if a noexcept function is reached, it may terminate the process. Other systems, such as macOS, do unwinding.
On Windows, this function calls _endthreadex(), which kills the thread without calling C++ destructors.
In any case, there is a risk of corruption on the thread’s stack.
Deprecated since version 3.14.
voidPyThread_init_thread(void)
Part of the
.Initialize PyThread* APIs. Python executes this function automatically, so there’s little need to call it from an extension module.
intPyThread_set_stacksize(size_tsize)
Part of the
.Set the stack size of the current thread to size bytes.
This function returns 0 on success, -1 if size is invalid, or -2 if the system does not support changing the stack size. This function does not set exceptions.
The caller does not need to hold an
.
size_tPyThread_get_stacksize(void)
Part of the
.Return the stack size of the current thread in bytes, or 0 if the system’s default stack size is in use.
The caller does not need to hold an
.