Hacker News Reader

Comment by stevefan1999 | Hacker News Reader

stevefan1999

No more fucking GIL bullshits

It doesn't have a GIL because it's using a lot of smaller individual locks. That ends up being much slower in practice.

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?

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.

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

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... !)

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).

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.

It has a GIL for now.

But if you are interested on removing the GIL, you gonna love 2022: https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf...

Oh, that's a big deal, yes. (For those unaware, GIL = global interpreter lock.)

I don’t think it’s a big deal if it’s not backwards compatible with the billions of lines of existing Python which use C extensions.

It's most likely that the GIL will be removed in the next 5 years: https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf...

Reply on news.ycombinator.com