You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update dependency-injector to run safely without the GIL #905
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.
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.
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.
Activity
ZipFile commentedon Jun 25, 2025
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.
romantolkachyov commentedon Jan 30, 2026
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.romantolkachyov commentedon Jan 31, 2026
Another important note I forget is that I creating containers sequentially inside threading.Lock. Also viable in my use-case.
kilianhammersmith171998 commentedon Oct 5, 2026
Hi, has there been any work towards this?