3 ms·

> 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 CPy

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

by kortex 3y ago

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.