4 ms·

That sounds like a maintenance and stability nightmare, if it's even possible. You are effectively red/blue splitting the entire codebase. PyObject and the GIL

by kortex 3y ago

That sounds like a maintenance and stability nightmare, if it's even possible. You are effectively red/blue splitting the entire codebase. PyObject and the GIL touch everything in the codebase.

amelius 3y ago
The red/blue splitting happens behind the scenes, so it's different. Not really a color problem, because the user doesn't have to know about it. But yeah, you will basically have two versions of Python running at the same time, with some (hopefully invisible) translation between them.
- kortex 3y ago
  > But the red/blue splitting happens behind the scenes, so it's different. Respectfully, I don't believe you have spent any appreciable time looking at the CPython source code. If you had, you would understand how unreasonable this expectation is. I don't say this to tear you down, I say this to convey the magnitude of what you are describing. It would involve touching tens of thousands of LoC. You are talking about a multi-million dollar project that would result in a ton of near-duplication of code. The red/blue is inescapable because you have to redefine PyObject to have two flavors, PyObject with GIL and GilFreePyObject. You now have to check which one you are dealing with constantly.
  - amelius 3y ago
    > You now have to check which one you are dealing with constantly. No, because if you're running inside a Thread you will know that you will see only PyObjects, whereas if you're running inside a GilFreeThread you will know that you will only see GilFreePyObjects. If you're manipulating the PyObject (necessarily from a Thread) then there will be behind-the-scenes translation code that will manipulate the corresponding GilFreePyObject for you. But you don't have to know about it.
    - kortex 3y ago
      What exactly does "running inside a Thread/GilFreeThread" in the context of the cpython runtime mean? You pretty much need an entire copy of the virtual machine code. These are C structs we are talking about here, not some Rust trait you can readily parameterize over abstractly. That either means lots of manual code duplication, or some gnarly preprocessor action. Both are a maintenance nightmare.
      - amelius 3y ago
        Yes, the assumption is that writing a "double-headed Python" runtime is far less work than converting the entire ecosystem to a new Python runtime. I think this is the correct view, because at this moment people are writing various approaches in an attempt at getting rid of the GIL. It's the ecosystem of modules that's the real problem, where you want to basically put in as little effort as possible per module, at least initially.
- nomel 3y ago
  Please read any amount of CPython interpreter code to begin to understand what you’re asking for “behind the scenes”.

by kortex 3y ago

That sounds like a maintenance and stability nightmare, if it's even possible. You are effectively red/blue splitting the entire codebase. PyObject and the GIL touch everything in the codebase.

amelius 3y ago

The red/blue splitting happens behind the scenes, so it's different. Not really a color problem, because the user doesn't have to know about it. But yeah, you will basically have two versions of Python running at the same time, with some (hopefully invisible) translation between them.

kortex 3y ago
> But the red/blue splitting happens behind the scenes, so it's different. Respectfully, I don't believe you have spent any appreciable time looking at the CPython source code. If you had, you would understand how unreasonable this expectation is. I don't say this to tear you down, I say this to convey the magnitude of what you are describing. It would involve touching tens of thousands of LoC. You are talking about a multi-million dollar project that would result in a ton of near-duplication of code. The red/blue is inescapable because you have to redefine PyObject to have two flavors, PyObject with GIL and GilFreePyObject. You now have to check which one you are dealing with constantly.
- amelius 3y ago
  > You now have to check which one you are dealing with constantly. No, because if you're running inside a Thread you will know that you will see only PyObjects, whereas if you're running inside a GilFreeThread you will know that you will only see GilFreePyObjects. If you're manipulating the PyObject (necessarily from a Thread) then there will be behind-the-scenes translation code that will manipulate the corresponding GilFreePyObject for you. But you don't have to know about it.
  - kortex 3y ago
    What exactly does "running inside a Thread/GilFreeThread" in the context of the cpython runtime mean? You pretty much need an entire copy of the virtual machine code. These are C structs we are talking about here, not some Rust trait you can readily parameterize over abstractly. That either means lots of manual code duplication, or some gnarly preprocessor action. Both are a maintenance nightmare.
    - amelius 3y ago
      Yes, the assumption is that writing a "double-headed Python" runtime is far less work than converting the entire ecosystem to a new Python runtime. I think this is the correct view, because at this moment people are writing various approaches in an attempt at getting rid of the GIL. It's the ecosystem of modules that's the real problem, where you want to basically put in as little effort as possible per module, at least initially.
nomel 3y ago
Please read any amount of CPython interpreter code to begin to understand what you’re asking for “behind the scenes”.