Skip to content

Update dependency-injector to run safely without the GIL #905

Description

@kazenshi

When running this library in a Python 3.13 project, I get the following warning:

<frozen importlib._bootstrap>:488: RuntimeWarning: The global interpreter lock (GIL) has been enabled to load module 'dependency_injector.containers', 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

I am fairly new to Python library development so I am not sure how I can help here.

Activity

  1. added theissue type on Jun 25, 2025
  2. ZipFile commented on Jun 25, 2025

    @ZipFile
    Contributor

    I am fairly new to Python library development so I am not sure how I can help here.

    Adding free-threding support would be non-trivial task. Cython starting v3.1 has some basic free-threading support, you can try experimenting with that. But either way, even if it builds and runs - there are brand new world of concurrency issues to solve. For sure there would be some issues around wiring, most likely something will pop out around longer-lived providers (singletons, resources). Should I mention we'll need some tests for multithreaded use case?

    There are plenty of work to do. As free-threding matures, we'll get there eventually. No ETA from my side atm.

  3. romantolkachyov commented on Jan 30, 2026

    @romantolkachyov
    Contributor

    Tried to run app with PYTHON_GIL=0 and python 3.14 for some time.

    Looks working while ones creates container per thread. I eventually catch weird errors like sigfaults when two threads using the same container under a heavy load.

    Also providers override() doesn't work (looks like provider overrides shared between threads) but I consider it single-thread-only and tests-only, so this is not an issue.

  4. romantolkachyov commented on Jan 31, 2026

    @romantolkachyov
    Contributor

    Another important note I forget is that I creating containers sequentially inside threading.Lock. Also viable in my use-case.

  5. kilianhammersmith171998 commented on Oct 5, 2026

    @kilianhammersmith171998

    Hi, has there been any work towards this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions