I suspect an interpreter that "solves" the GIL problem will break tons of modules that currently only work in concurrent contexts because the GIL exists.
Jython and IronPython can work without a GIL more easily than CPython because they don’t support native (C-based) extension modules. Does RustPython intend to support existing Python extensions written in C?
They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. Do they add a lock around each individual object?
> They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model.
"Ownership models" are not a given. C++ has no "ownership model" and it doesn't lock around objects. Multi-threading users are just given the synchronization primitives and are expected to manage their own solutions.
The main thing that's keeping the GIL around is the reference-counting garbage collector. If your python implementation uses its own GC mechanism, it doesn't have this problem.
FreeBSD went through a similar issue back in the late 90s, early 2000s when they added pervasive multithreading into the kernel.
The GIL isn't some halting problem level thing. As you allude to, Python could definitely decide to go multithreaded and add in the requisite locks. They haven't.
I really wish that the PSF would
* Make a spec
* Break out the stdlib into a portable library, and by portable, something that can be shared across PyPy, Graal, Jython, etc.
Most languages with proper multithreading that I've used don't have an ownership model. Most the the standard library collection types are explicitly not thread safe, and then there's separate concurrent versions for if you're writing multithreaded code. And you're given locking/mutex primitives if you want to roll your own stuff.
