Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Free-threaded Python (3.14t/3.15t): importing _objtrace re-enables the GIL

Abierto
  • ¿Algo no está bien?
#867 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
39/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, build-system, documentation, performance, testing

Línea de trabajo

Start with scout_apm/core/objtrace.py and the _objtrace C extension; inspect how the fallback is selected and where the extension declares module slots. Then review .github/workflows/main.yml and the tox environment selection for Python 3.14t and 3.15t. The issue proposes a short term fallback and CI coverage, while making the extension free-threading safe requires investigation and stress tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

We publish free-threaded wheels (cp314t and cp315t). For example, scout-apm 4.0.0 on PyPI includes scout_apm-4.0.0-cp314-cp314t-*.whl, and cibuildwheel builds cp315t wheels on master. But nothing in CI tests the free-threaded builds, and the _objtrace C extension never declares that it's safe to run without the GIL. It has no Py_mod_gil slot.

So when scout_apm.core.install() imports scout_apm.core._objtrace on a free-threaded interpreter, CPython turns the GIL back on for the whole process:

RuntimeWarning: The global interpreter lock (GIL) has been enabled to load module 'scout_apm.core._objtrace', which has not declared that it can run safely without the GIL. To override this behavior and keep the GIL disabled (at your own risk), run with PYTHON_GIL=0 or -Xgil=0.

The impact:

  • Any free-threaded app with scout-apm installed quietly loses free-threading. sys._is_gil_enabled() becomes True after the import.
  • When warnings are errors (-W error, or our own pytest.ini), the import raises RuntimeWarning. The fallback in objtrace.py only catches ImportError, so the exception isn't handled. A free-threaded CI job would fail on this right away.

Reproduce

uv venv -p 3.15t venv && VIRTUAL_ENV=venv uv pip install "scout-apm @ ."
venv/bin/python -c "import sys; from scout_apm.core import objtrace; print(objtrace.is_extension, sys._is_gil_enabled())"
# RuntimeWarning as above, then: True True

What objtrace provides

objtrace only produces the per-span allocation tags: allocations, start_allocations and stop_allocations (tracked_request.py, add_allocation_tags). Memory increase per request (RSS via psutil) and the memory sampler don't depend on it. The agent already runs without objtrace on PyPy, with SCOUT_DISABLE_EXTENSIONS=1, and whenever the optional extension fails to compile. In those cases add_allocation_tags() just skips the tags.

Proposed plan

  1. Short term: on free-threaded builds, use the existing no-op fallback in objtrace.py instead of importing the extension, for example when sysconfig.get_config_var("Py_GIL_DISABLED") is set. The GIL stays off, and allocation tags are skipped like they are on PyPy.
  2. CI: add 3.14t and 3.15t jobs, with py314t-* and py315t-* tox envs. The env selection in main.yml currently strips the version down to digits (3.15t becomes 315) and matches ^py315 as a prefix, so it would also need to match the t suffix exactly.
  3. Longer term (needs investigation): make _objtrace actually safe without the GIL and declare Py_MOD_GIL_NOT_USED. The counters are already thread-local (__thread). The open questions:
    • enable() and disable() read and write installed without a lock. A concurrent double enable() would wrap our own hook and recurse infinitely.
    • We'd need to confirm whether calling PyMem_SetAllocator at runtime, while other threads are allocating, is safe on free-threaded CPython.
    • Stress tests on 3.14t/3.15t would be needed before shipping.
  4. Docs: say which Python builds and interpreters report allocation counts. Today the docs don't mention objtrace, PyPy or SCOUT_DISABLE_EXTENSIONS at all.

Found while adding Python 3.15 CI in #866.

Lenguaje dominante
Python
Estrellas
77
Forks
19
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de scoutapp/scout_apm_python

Todos los issues de scoutapp/scout_apm_python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.