On: Python interpreter written in rust reaches 10000 c...

[prabhu-yu]

Are you sure, this does not have the GIL? I tried looking into documentation, I could not find such info. Can you please point the link?

[the_mitsuhiko → prabhu-yu]

It does not have a GIL but this also means it's not compatible with a lot of Python code that needs a GIL or C-extensions. Not having a GIL by itself is not tricky, being compatible and not having a GIL is.

[hannibalhorn → the_mitsuhiko]

I believe Python C-API compatibility isn't a really a goal for this implementation anyway. [1] HPy sounds like the best path forward?

1. https://github.com/RustPython/RustPython/issues/1940

[abledon → the_mitsuhiko]

why can't they implement a 'fake' GIL flag for those programs? so its backward compatible. (Yeah its probably a lot more work to write those extra modules/code paths... !)

[Joker_vD → abledon]

It's not a "flag", really: it's a fundamental, implicit underlying assumption about the execution environment. The C extensions assume (roughly) that if they're executing, they can touch any part of the runtime without any synchronization whatsoever, because nobody else is executing (that's what GIL ensures).

[jerf → Joker_vD]

Or, to put it another way, it's the first letter of the acronym: "Global Interpreter Lock".

You can't really "fake" a global lock. Either you're globally locking everywhere with the global lock or you aren't.