4 ms·
Yep there are a ton of issues like that to be found, and unfortunately they will manifest as difficult to find and debug race conditions. This is why the propo
by qbasic_forever 3y ago
Yep there are a ton of issues like that to be found, and unfortunately they will manifest as difficult to find and debug race conditions. This is why the proposal and work is to make non-GIL mode entirely optional and not the default.
It just means for the brave few that flip it on and use it, be prepared to spend a huge amount of time finding and fixing subtle race conditions in decades of old python library code. The early adopters are going to be in for a lot of pain, or more likely they'll restrict their use of non-GIL processes to very specialized and dedicated processes that have as few dependencies as possible.
- miraculixx 3y agoThe intent is to make no GIL the default eventually.
- n2d4 3y agoI don't think this is true. There are fairly strong voices on both sides inside the community, at this time it's pretty uncertain. To quote Guido: >Let’s not blow it this time. If we’re going forward with nogil (and I’m not saying we are, but I can’t exclude it), let’s make sure there is a way to be able to import extensions requiring the GIL in a nogil interpreter without any additional shenanigans https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/19 https://discuss.python.org/t/pep-703-making-the-global-inter...
- Alphaeus 3y agoThe Steering Council said their intention is to remove the GIL-build in future: > Long-term, we want no-GIL to be the default, and to remove any vestiges of the GIL (without unnecessarily breaking backward compatibility). We don’t want to wait too long with this, because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage. https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474 https://discuss.python.org/t/a-steering-council-notice-about...
- toyg 3y agoBy the usual laws of software estimates, if they think it will take 5 years, it's going to be more like 10-15.
- hinkley 3y agoDoes Python have a lot of secondary dependencies? I could see someone pulling in two dependencies, not realize they both use the same unsafe library, and end up having them step all over each other.
- qbasic_forever 3y agoIt does, so much so things like virtualenv were introduced so every program can have its own set of dependencies such that they won't clash with other libs on your system. Something like flask or fastapi pull in a lot of secondary dependencies alone.
- hinkley 3y agoProbably doesn't work with FFI though? I'm trying to get a sense of how hypothetical versus very real this problem is.