On Fri, 29 May 2020 14:19:40 -0000 firstname.lastname@example.org wrote:
Yesterday RustPython team finished threading without GIL: https://github.com/RustPython/RustPython/issues/1831
So what? As was pointed out, there're bunch of Python implementations which don't use GIL. And it's very easy to stop caring about GIL, there're roughly 3 ways to deal with the problem:
1. Don't use threads, don't need to care about GIL. This is the choice of the people of 21st century.
2. Don't share data among the threads, don't have problem. Smart among us can constrain themselves with just a power of will, everyone else needs to get a separate heap per thread (or separate roots in the same heap, but that's impl detail), so they couldn't do that even they want. Oh, they could - as long as data is constant. Constness matters! This is the way which everyone and their grandma uses in the area of programming languages. Even CPython gets that in the shape of "interpreters" module.
3. Instead of GIL, have fine-grained per-object locks. That's the Java way, which stuffs a lock field into each object, even though 99.9% of them will never need it.
All these 3 ways of doing concurrency were available for Python for ages, and whoever needed them, used them. GIL, and complaining about it, is strictly a paraphernalia of users of a particular implementation, CPython.