# Thread states and the global interpreter lock

Unless on a free-threaded build of CPython, the Python interpreter is generally not 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 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 `sys.setswitchinterval()`). 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 detaching the thread state.

The Python interpreter keeps some thread-local information inside a data structure called `PyThreadState`, known as a thread state. Each thread has a thread-local pointer to a `PyThreadState`; a thread state referenced by this pointer is considered to be attached.

A thread can only have one attached thread state 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.

Nota

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 `Py_BEGIN_ALLOW_THREADS` block or in a fresh thread, will the thread not have an attached thread state. If uncertain, check if `PyThreadState_GetUnchecked()` returns `NULL`.

If it turns out that you do need to create a thread state, it is recommended to use `PyThreadState_Ensure()` or `PyThreadState_EnsureFromView()`, which will manage the thread state for you.

## Desvinculação do estado de thread do código de extensão

A maior parte do código de extensão que manipula o estado de thread tem a seguinte estrutura simples:

    Salve o estado de thread em uma variável local.
    ... Faça alguma operação de E/S com bloqueio...
    Restaure o estado de thread da variável local.

Isso é tão comum que existe um par de macros para simplificá-lo:

    Py_BEGIN_ALLOW_THREADS
    ... Faça alguma operação de E/S com bloqueio...
    Py_END_ALLOW_THREADS

A macro `Py_BEGIN_ALLOW_THREADS` abre um novo bloco e declara uma variável local oculta; a macro `Py_END_ALLOW_THREADS` fecha o bloco.

O bloco acima se expande para o seguinte código:

    PyThreadState *_save;

    _save = PyEval_SaveThread();
    ... Faça alguma operação de E/S com bloqueio...
    PyEval_RestoreThread(_save);

Veja como essas funções atuam:

The attached thread state implies that the GIL is held for the interpreter. To detach it, `PyEval_SaveThread()` 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 `PyEval_RestoreThread()`, which will wait until the GIL can be acquired.

Nota

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 `zlib` and `hashlib` modules detach the thread state when compressing or hashing data.

On a free-threaded build, the GIL 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.

Aviso

Detaching the thread state can lead to unexpected behavior during interpreter finalization. See Cautions regarding interpreter finalization for more details.

### APIs

The following macros are normally used without a trailing semicolon; look for example usage in the Python source distribution.

Nota

These macros are still necessary on the free-threaded build to prevent deadlocks.

Py_BEGIN_ALLOW_THREADS
  Parte da ABI Estável.

  Esta macro se expande para `{ PyThreadState *_save; _save = PyEval_SaveThread();`. Observe que ele contém uma chave de abertura; ele deve ser combinado com a seguinte macro `Py_END_ALLOW_THREADS`. Veja acima para uma discussão mais aprofundada desta macro.

Py_END_ALLOW_THREADS
  Parte da ABI Estável.

  Esta macro se expande para `PyEval_RestoreThread(_save); }`. Observe que ele contém uma chave de fechamento; ele deve ser combinado com uma macro `Py_BEGIN_ALLOW_THREADS` anterior. Veja acima para uma discussão mais aprofundada desta macro.

Py_BLOCK_THREADS
  Parte da ABI Estável.

  Esta macro se expande para `PyEval_RestoreThread(_save);`: é equivalente a `Py_END_ALLOW_THREADS` sem a chave de fechamento.

Py_UNBLOCK_THREADS
  Parte da ABI Estável.

  Esta macro se expande para `_save = PyEval_SaveThread();`: é equivalente a `Py_BEGIN_ALLOW_THREADS` sem a chave de abertura e declaração de variável.

## Using the C API from foreign threads

When threads are created using the dedicated Python APIs (such as the `threading` 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 easiest way to do this is through `PyThreadState_Ensure()` or `PyThreadState_EnsureFromView()`.

Nota

These functions require an argument pointing to the desired interpreter; such a pointer can be acquired via a call to `PyInterpreterGuard_FromCurrent()` (for `PyThreadState_Ensure`) or `PyInterpreterView_FromCurrent()` (for `PyThreadState_EnsureFromView`) from the function that creates the thread. If no pointer is available (such as when the given native thread library doesn’t provide a data argument), `PyInterpreterView_FromMain()` can be used to get a view for the main interpreter, but note that this will make the code incompatible with subinterpreters.

Por exemplo:

    // The return value of PyInterpreterGuard_FromCurrent() from the
    // function that created this thread.
    PyInterpreterGuard *guard = thread_data->guard;

    // Create a new thread state for the interpreter.
    PyThreadStateToken *token = PyThreadState_Ensure(guard);
    if (token == NULL) {
       PyInterpreterGuard_Close(guard);
       return;
    }

    // We have a valid thread state -- perform Python actions here.
    result = CallSomeFunction();
    // Evaluate result or handle exceptions.

    // Release the thread state. No calls to the C API are allowed beyond this
    // point.
    PyThreadState_Release(token);
    PyInterpreterGuard_Close(guard);

Keep in mind that calling `PyThreadState_Ensure` might not always create a new thread state, and calling `PyThreadState_Release` might not always detach it. These functions may reuse an existing attached thread state, or may re-attach a thread state that was previously attached for the current thread.

Ver também

PEP 788

### Attaching/detaching thread states

PyThreadStateToken *PyThreadState_Ensure(PyInterpreterGuard *guard)
  Parte da ABI Estável desde a versão 3.15.

  Ensure that the thread has an attached thread state for the interpreter protected by guard, and thus can safely invoke that interpreter.

  It is OK to call this function if the thread already has an attached thread state, as long as there is a subsequent call to `PyThreadState_Release()` that matches this one (meaning that “nested” calls to this function are permitted).

  The function’s effect (if any) will be reversed by the matching call to `PyThreadState_Release()`.

  On error, this function returns `NULL` without an exception set. Do not call `PyThreadState_Release()` in this case.

  On success, this function returns a pointer value that must be passed to the matching call to `PyThreadState_Release()`.

  The conditions in which this function creates a new thread state are considered unstable and implementation-dependent. If you need to control the exact lifetime of a thread state, consider using `PyThreadState_New()`. However, do not avoid this function solely on the basis that the lifetime of the thread state may be inconsistent across versions; changes to this function will be done with caution and in a backwards-compatible manner. In particular, the saving of thread-local variables and similar state will be retained across Python versions.

  Detalhes da implementação do CPython: The exact behavior of whether this function creates a new thread state is described below, but be aware that this may change in the future.

  First, this function checks if an attached thread state is present. If there is, this function then checks if the interpreter of that thread state matches the interpreter guarded by guard. If that is the case, this function simply marks the thread state as being used by a `PyThreadState_Ensure` call and returns.

  If there is no attached thread state, then this function checks if any thread state has been used by the current OS thread. (This is returned by `PyGILState_GetThisThreadState()`.) If there was, then this function checks if that thread state’s interpreter matches guard. If it does, it is re-attached and marked as used.

  Otherwise, if both of the above cases fail, a new thread state is created for guard. It is then attached and marked as owned by `PyThreadState_Ensure`.

  Adicionado na versão 3.15.

PyThreadStateToken *PyThreadState_EnsureFromView(PyInterpreterView *view)
  Parte da ABI Estável desde a versão 3.15.

  Get an attached thread state for the interpreter referenced by view.

  The behavior and return value are the same as for `PyThreadState_Ensure()`; additionally, if the function succeeds, the interpreter referenced by view will be implicitly guarded. The guard will be released upon the corresponding `PyThreadState_Release()` call.

  Adicionado na versão 3.15.

void PyThreadState_Release(PyThreadStateToken *token)
  Parte da ABI Estável desde a versão 3.15.

  Undo a `PyThreadState_Ensure()` or `PyThreadState_EnsureFromView()` call.

  This must be called exactly once for each successful Ensure call, with token set to that call’s return value.

  The state that was attached before the corresponding Ensure call (if any) will be attached when `PyThreadState_Release()` returns.

  The exact behavior of whether this function deletes a thread state is considered unstable and implementation-dependent.

  Detalhes da implementação do CPython: Currently, this function will decrement an internal counter on the attached thread state. If this counter ever reaches below zero, this function emits a fatal error (via `Py_FatalError()`).

  If the attached thread state is owned by `PyThreadState_Ensure`, then the attached thread state will be deallocated and deleted upon the internal counter reaching zero. Otherwise, nothing happens when the counter reaches zero.

  Adicionado na versão 3.15.

type PyThreadStateToken
  Parte da ABI Estável (como uma estrutura opaca) desde a versão 3.15.

  An opaque token retrieved from a `PyThreadState_Ensure()` call and passed to a corresponding `PyThreadState_Release()` call.

## GIL-state APIs

The following APIs are generally not compatible with subinterpreters and will hang the process during interpreter finalization (see Cautions regarding interpreter finalization). As such, these APIs were soft deprecated in Python 3.15 in favor of the new APIs.

type PyGILState_STATE
  Parte da ABI Estável.

  The type of the value returned by `PyGILState_Ensure()` and passed to `PyGILState_Release()`.

  enumerator PyGILState_LOCKED

    The GIL was already held when `PyGILState_Ensure()` was called.

  enumerator PyGILState_UNLOCKED

    The GIL was not held when `PyGILState_Ensure()` was called.

PyGILState_STATE PyGILState_Ensure()
  Parte da ABI Estável.

  Ensure that the current thread is ready to call the Python C API regardless of the current state of Python, or of the attached thread state. This may be called as many times as desired by a thread as long as each call is matched with a call to `PyGILState_Release()`. In general, other thread-related APIs may be used between `PyGILState_Ensure()` 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 `Py_BEGIN_ALLOW_THREADS` and `Py_END_ALLOW_THREADS` macros is acceptable.

  The return value is an opaque “handle” to the attached thread state when `PyGILState_Ensure()` was called, and must be passed to `PyGILState_Release()` 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 attached thread state and the thread will be able to call arbitrary Python code.

  This function has no way to return an error. As such, errors are either fatal (that is, they send `SIGABRT` and crash the process; see `Py_FatalError()`), or the thread will be permanently blocked (such as during interpreter finalization).

  Aviso

  Calling this function when the interpreter is finalizing will infinitely hang the thread, which may cause deadlocks. Cautions regarding interpreter finalization for more details.

  In addition, this function generally does not work with subinterpreters when used from foreign threads, because this function has no way of knowing which interpreter created the thread (and as such, will implicitly pick the main interpreter).

  Alterado na versão 3.14: Hangs the current thread, rather than terminating it, if called while the interpreter is finalizing.

  Suavemente descontinuado desde a versão 3.15: Use `PyThreadState_Ensure()` or `PyThreadState_EnsureFromView()` instead.

void PyGILState_Release(PyGILState_STATE)
  Parte da ABI Estável.

  Release any resources previously acquired. After this call, Python’s state will be the same as it was prior to the corresponding `PyGILState_Ensure()` call (but generally this state will be unknown to the caller, hence the use of the GIL-state API).

  Every call to `PyGILState_Ensure()` must be matched by a call to `PyGILState_Release()` on the same thread.

  Suavemente descontinuado desde a versão 3.15: Use `PyThreadState_Release()` instead.

PyThreadState *PyGILState_GetThisThreadState()
  Parte da ABI Estável.

  Get the thread state that was most recently attached for this thread. (If the most recent thread state has been deleted, this returns `NULL`.)

  If the caller has an attached thread state, it is returned.

  In other terms, this function returns the thread state that will be used by `PyGILState_Ensure()`. If this returns `NULL`, then `PyGILState_Ensure` will create a new thread state.

  This function cannot fail.

  Suavemente descontinuado desde a versão 3.15: Use `PyThreadState_Get()` or `PyThreadState_GetUnchecked()` instead.

int PyGILState_Check()

  Return `1` if the current thread has an attached thread state that matches the thread state returned by `PyGILState_GetThisThreadState()`. If the caller has no attached thread state or it otherwise doesn’t match, then this returns `0`.

  If the current Python process has ever created a subinterpreter, this function will always return `1`.

  This is mainly a helper/diagnostic function.

  Adicionado na versão 3.4.

  Suavemente descontinuado desde a versão 3.15: Use `PyThreadState_GetUnchecked() != NULL` instead.

## Cuidados com o uso de fork()

Outro aspecto importante a observar sobre threads é o seu comportamento diante da chamada de `fork()` da linguagem C. Na maioria dos sistemas com `fork()`, após um processo ser criado (“fork”), apenas a thread que emitiu o fork continuará existindo. Isso tem um impacto concreto tanto na forma como as travas devem ser gerenciados quanto em todo o estado armazenado no ambiente de execução do CPython.

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

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

## APIs de alto nível

These are the most commonly used types and functions when writing multi-threaded C extensions.

type PyThreadState
  Parte da ABI Estável (como uma estrutura opaca).

  This data structure represents the state of a single thread. The only public data member is:

  PyInterpreterState *interp

    This thread’s interpreter state.

void PyEval_InitThreads()
  Parte da ABI Estável.

  Função descontinuada que não faz nada.

  In Python 3.6 and older, this function created the GIL if it didn’t exist.

  Alterado na versão 3.9: The function now does nothing.

  Alterado na versão 3.7: Esta função agora é chamada por `Py_Initialize()`, então não há mais necessidade de você chamá-la.

  Alterado na versão 3.2: Esta função não pode mais ser chamada antes de `Py_Initialize()`.

  Descontinuado desde a versão 3.9.

PyThreadState *PyEval_SaveThread()
  Parte da ABI Estável.

  Detach the attached thread state and return it. The thread will have no thread state upon returning.

void PyEval_RestoreThread(PyThreadState *tstate)
  Parte da ABI Estável.

  Set the attached thread state to tstate. The passed thread state should not be attached, otherwise deadlock ensues. tstate will be attached upon returning.

  Nota

  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 interpreter finalization for more details.

  Alterado na versão 3.14: Hangs the current thread, rather than terminating it, if called while the interpreter is finalizing.

PyThreadState *PyThreadState_Get()
  Parte da ABI Estável.

  Return the attached thread state. If the thread has no attached thread state, (such as when inside of `Py_BEGIN_ALLOW_THREADS` block), then this issues a fatal error (so that the caller needn’t check for `NULL`).

  See also `PyThreadState_GetUnchecked()`.

PyThreadState *PyThreadState_GetUnchecked()

  Similar to `PyThreadState_Get()`, 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.

  Adicionado na versão 3.13: In Python 3.5 to 3.12, the function was private and known as `_PyThreadState_UncheckedGet()`.

PyThreadState *PyThreadState_Swap(PyThreadState *tstate)
  Parte da ABI Estável.

  Set the attached thread state to tstate, and return the thread state that was attached prior to calling.

  This function is safe to call without an attached thread state; it will simply return `NULL` indicating that there was no prior thread state.

  Ver também

  `PyEval_ReleaseThread()`

  Nota

  Similar to `PyGILState_Ensure()`, this function will hang the thread if the runtime is finalizing.

## APIs de baixo nível

PyThreadState *PyThreadState_New(PyInterpreterState *interp)
  Parte da ABI Estável.

  Create a new thread state object belonging to the given interpreter object. An attached thread state is not needed.

void PyThreadState_Clear(PyThreadState *tstate)
  Parte da ABI Estável.

  Reset all information in a thread state object. tstate must be attached

  Alterado na versão 3.9: This function now calls the `PyThreadState.on_delete` callback. Previously, that happened in `PyThreadState_Delete()`.

  Alterado na versão 3.13: The `PyThreadState.on_delete` callback was removed.

void PyThreadState_Delete(PyThreadState *tstate)
  Parte da ABI Estável.

  Destroy a thread state object. tstate should not be attached to any thread. tstate must have been reset with a previous call to `PyThreadState_Clear()`.

void PyThreadState_DeleteCurrent(void)

  Detach the attached thread state (which must have been reset with a previous call to `PyThreadState_Clear()`) and then destroy it.

  No thread state will be attached upon returning.

PyFrameObject *PyThreadState_GetFrame(PyThreadState *tstate)
  Parte da ABI Estável desde a versão 3.10.

  Get the current frame of the Python thread state tstate.

  Return a strong reference. Return `NULL` if no frame is currently executing.

  See also `PyEval_GetFrame()`.

  tstate must not be `NULL`, and must be attached.

  Adicionado na versão 3.9.

uint64_t PyThreadState_GetID(PyThreadState *tstate)
  Parte da ABI Estável desde a versão 3.10.

  Get the unique thread state identifier of the Python thread state tstate.

  tstate must not be `NULL`, and must be attached.

  Adicionado na versão 3.9.

PyInterpreterState *PyThreadState_GetInterpreter(PyThreadState *tstate)
  Parte da ABI Estável desde a versão 3.10.

  Get the interpreter of the Python thread state tstate.

  tstate must not be `NULL`, and must be attached.

  Adicionado na versão 3.9.

void PyThreadState_EnterTracing(PyThreadState *tstate)

  Suspend tracing and profiling in the Python thread state tstate.

  Resume them using the `PyThreadState_LeaveTracing()` function.

  Adicionado na versão 3.11.

void PyThreadState_LeaveTracing(PyThreadState *tstate)

  Resume tracing and profiling in the Python thread state tstate suspended by the `PyThreadState_EnterTracing()` function.

  See also `PyEval_SetTrace()` and `PyEval_SetProfile()` functions.

  Adicionado na versão 3.11.

int PyUnstable_ThreadState_SetStackProtection(PyThreadState *tstate, void *stack_start_addr, size_t stack_size)
  Esta é uma API Instável. Isso pode se alterado sem aviso em lançamentos menores.

  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 recursion control for C code by raising `RecursionError` when it notices that the machine execution stack is close to overflow. See for example the `Py_EnterRecursiveCall()` 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.

  Adicionado na versão 3.15.

void PyUnstable_ThreadState_ResetStackProtection(PyThreadState *tstate)
  Esta é uma API Instável. Isso pode se alterado sem aviso em lançamentos menores.

  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.

  Adicionado na versão 3.15.

PyObject *PyThreadState_GetDict()
  Retorna valor: Referência emprestada. Parte da ABI Estável.

  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 thread state is attached. If this function returns `NULL`, no exception has been raised and the caller should assume no thread state is attached.

void PyEval_AcquireThread(PyThreadState *tstate)
  Parte da ABI Estável.

  Attach tstate to the current thread, which must not be `NULL` or already attached.

  The calling thread must not already have an attached thread state.

  Nota

  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 interpreter finalization for more details.

  Alterado na versão 3.8: Updated to be consistent with `PyEval_RestoreThread()`, `Py_END_ALLOW_THREADS()`, and `PyGILState_Ensure()`, and terminate the current thread if called while the interpreter is finalizing.

  Alterado na versão 3.14: Hangs the current thread, rather than terminating it, if called while the interpreter is finalizing.

  `PyEval_RestoreThread()` is a higher-level function which is always available (even when threads have not been initialized).

void PyEval_ReleaseThread(PyThreadState *tstate)
  Parte da ABI Estável.

  Detach the attached thread state. 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.

  `PyEval_SaveThread()` 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.

int Py_AddPendingCall(int (*func)(void*), void *arg)
  Parte da ABI Estável.

  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 an attached thread state (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 thread state is detached.

  This function doesn’t need an attached thread state. 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.

  Aviso

  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 `PyThreadState_EnsureFromView()`.

  Adicionado na versão 3.1.

  Alterado na versão 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.

  Alterado na versão 3.12: This function now always schedules func to be run in the main interpreter.

int Py_MakePendingCalls(void)
  Parte da ABI Estável.

  Execute all pending calls. This is usually executed automatically by the interpreter.

  Esta função retorna `0` em caso de sucesso e retorna `-1` com uma exceção definida em caso de falha.

  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 attached thread state.

  Adicionado na versão 3.1.

  Alterado na versão 3.12: This function only runs pending calls in the main interpreter.

int PyThreadState_SetAsyncExc(unsigned long id, PyObject *exc)
  Parte da ABI Estável.

  Schedule an exception to be raised asynchronously in a thread. If the thread has a previously scheduled exception, it is overwritten.

  The id argument is the thread id of the target thread, as returned by `PyThread_get_thread_ident()`. exc is the class of the exception to be raised, or `NULL` to clear the pending exception (if any).

  Return the number of affected thread states. This is normally `1` if id is found, even when no change was made (the given exc was already pending, or exc is `NULL` but no exception is pending). If the thread id isn’t found, return `0`. This raises no exceptions.

  To prevent naive misuse, you must write your own C extension to call this. This function must be called with an attached thread state. This function does not steal any references to exc. This function does not necessarily interrupt system calls such as `sleep()`.

  Alterado na versão 3.7: The type of the id parameter changed from long to unsigned long.

# Operating system thread APIs

PYTHREAD_INVALID_THREAD_ID

  Sentinel value for an invalid thread ID.

  This is currently equivalent to `(unsigned long)-1`.

unsigned long PyThread_start_new_thread(void (*func)(void*), void *arg)
  Parte da ABI Estável.

  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 `PYTHREAD_INVALID_THREAD_ID`.

  The caller does not need to hold an attached thread state.

unsigned long PyThread_get_thread_ident(void)
  Parte da ABI Estável.

  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 attached thread state.

  Ver também

  `threading.get_ident()` and `threading.Thread.ident` expose this identifier to Python.

PyObject *PyThread_GetInfo(void)
  Parte da ABI Estável desde a versão 3.3.

  Get general information about the current thread in the form of a struct sequence object. This information is accessible as `sys.thread_info` in Python.

  On success, this returns a new strong reference to the thread information; on failure, this returns `NULL` with an exception set.

  The caller must hold an attached thread state.

PY_HAVE_THREAD_NATIVE_ID

  This macro is defined when the system supports native thread IDs.

unsigned long PyThread_get_thread_native_id(void)
  Parte da ABI Estável 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 `PY_HAVE_THREAD_NATIVE_ID` is defined.

  This function cannot fail, and the caller does not need to hold an attached thread state.

  Ver também

  `threading.get_native_id()`

void PyThread_exit_thread(void)
  Parte da ABI Estável.

  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.

  Aviso

  If the current system uses POSIX threads (also known as “pthreads”), this calls pthread_exit(3), 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.

  Descontinuado desde a versão 3.14.

void PyThread_init_thread(void)
  Parte da ABI Estável.

  Initialize `PyThread*` APIs. Python executes this function automatically, so there’s little need to call it from an extension module.

int PyThread_set_stacksize(size_t size)
  Parte da ABI Estável.

  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 attached thread state.

size_t PyThread_get_stacksize(void)
  Parte da ABI Estável.

  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 attached thread state.