Reading the article will clarify.
Is execution_loop really meant to start and end holding the GIL?
As for empty lines within code, I personally find it helpful to visually separate logical segments.
I see it as, if a function is like a paragraph, then the whitespace between lines deliminates sentences. I very much dislike run on sentences that are attempting to explain complex rules/topics in english and in code. Spatial grouping is very natural for the eyes and mind.
So much for "implemented".
Incidentally, apparently PyPy has a GIL too, complete with a detailed description in a source-code comment, similar to the one quoted in the linked article. It's written in C. Isn't the point of PyPy that it's written in a Python subset?
This comment reeks of middlebrow dismissal. The author implemented the GIL in pure Python for illustration purposes, as it says in the very first paragraph of the article, yet you complain it won't actually run. Where were you thinking of using a pure-Python GIL that this is such an inconvenience to you?
> Isn't the point of PyPy that it's written in a Python subset?
More dismissal. The point of PyPy is to be a JIT. What it's written in is incidental, not "the point".
As to my second point, you're reading dismissal where there is none intended. My question wasn't rhetorical. Ironically, you've just dismissed my question.
Is Wikipedia's PyPy article mistaken in describing it as 'Written in RPython'? I'll go ahead and fix it if so, or perhaps I'm missing something about the status of the C code.
The GIL is fully implemented. Just because it's typically seen with a bytecode interpreter doesn't make that such an interpreter is part of it, or a prerequisite.
PyPy is written in RPython. You posted a link to the RPython translator's source code.
I'd probably go with "The GIL explained in Python".
> PyPy is written in RPython. You posted a link to the RPython translator's source code.
But RPython is a part of the PyPy project, no?
Do you consider the Wikipedia listing to be accurate?
Because PyPy on CPython is never going to be faster than CPython alone, the RPython toolchain is used to convert the PyPy interpreter to C code. The C code in the RPython source (e.g. the GIL implementation) is bundled together with the translated program and then compiled into machine code.
RPython is also written in Python. It works by importing the program to be translated, executing all initialization code to create classes, methods and global objects. This is no different from regular program startup. But then RPython is provided with a particular function as an entry point, and it does whole-program type inference to determine a static type for every reachable value. That only works because PyPy is written in a style that only uses dynamic Python features during initialization and is very restricted after the entry point. So PyPy is actually written in the subset of Python that RPython accepts.
If you tried to use RPython on any arbitrary Python program, it'd probably complain about a ton of type errors. RPython is really a very different language, and its feature set is tailored specifically to writing PyPy in it. It can handle certain constructs that Mypy isn't able to typecheck because they require running the program, but it also rejects many well-typed Python constructs because they don't translate to efficient C.
I do consider the Wikipedia listing accurate, yes.
That subset is rpython (which beyond a python subset is a framework for implementing dynamic language runtimes: https://rpython.readthedocs.io/en/latest/).
You'll note that the gil is part of rpython.
Why would you need a working GIL inside the GIL?