> The GIL is an implementation detail, not poor language design.
As I understood the GIL simplifies data structures by removing any regard for concurrent access.
If you remove the GIL you must move your synchronization (mutexes) into the data structures and immediately get a big performance penalty.
If you wanted to avoid this overhead you run into swamplands where the programmer must take care of concurrent access patterns and everything. Also many CPython modules would stop working because they assume the GIL.
It can be done but last time I read about the GILectomy there was no clear way forward.
Yeah, I think this kind of issue is why Ruby, which also has a GIL, seems to be heading for a new concurrency and parallelism model that introduces a new level (Guilds) between threads and processes where the big lock would be held, and where Guilds communicate only by sharing read access to immutable data, and transferring ownership or copies of mutable data.
As I understood the GIL simplifies data structures by removing any regard for concurrent access.
If you remove the GIL you must move your synchronization (mutexes) into the data structures and immediately get a big performance penalty.
If you wanted to avoid this overhead you run into swamplands where the programmer must take care of concurrent access patterns and everything. Also many CPython modules would stop working because they assume the GIL.
It can be done but last time I read about the GILectomy there was no clear way forward.