Any Updates or new Commits?

[ELind77]

I've watched both of your talks on the Gilectomy project online and I read the thread here: https://lwn.net/Articles/723514/ but I haven't seen any updates to this repo. In your talk you even mentioned commits that appeared to be more recent than what's here. Is there somewhere else I should be looking for updates or new commits?

I'm not a core CPython contributor but as I use Cython and C++ more and more I look at this project as something that would be a great motivator for me to learn more and try to contribute. But that's really difficult if I can't tell what the state of the project is.

Eric

[ghost]

I think that larry has come to the conclusion that CPython is too complex at this point to make such a fundamental change. The reality is that you're fighting against bit rot induced by the thousands of contributions going into CPython every release.

Also, the approach seems wrong to me. The fact is that the implementor is never going to be able to guess all of the use cases, so they need to guard against every bad thing the user might do. I think that the approach should be (as I have said not-so-gracefully earlier) that the GIL should optionally be disabled with a with nogil statement or something of that nature and it should be left up to the user to avoid concurrent object access (and segmentation fault). Then there are a few special cases to handle such as copying the range of numbers into a new thread. But implementing a compile-time decision about the GIL is too restrictive and will slow the vast majority of existing programs down.

[thedrow]

@xoviat Is that just a guess or have you talked to him about it?

[ghost]

It's both obvious from first principles and where @larryhastings is spending his time. I'll eat my words if proven otherwise.​

[ghost]

To clarify, it's very easy for me to stand on the sidelines and criticize the work of others. But the reality is that a single programmer working in their free time is not going to take the GIL out of CPython if its CPython's responsibility to prevent a segmentation fault. C is a tricky language. Sure, it's not C++, but it's tricky enough to make people prefer Python (or something like Cython). And another way to put that is that C reduces a programmer's "maximum potential" because it's more difficult to accomplish the same thing in C as in something like Python. Incidentally, I think that PyPy has a good chance of removing the GIL. But PyPy has at least one full-time programmer working on the problem in a language (RPython) that enables a programmer to have a significantly higher "maximum potential" than C. The entire reason project managers exist is to ensure that a (the programmer) + b (the implementation language) = c (the product). In this case, they don't add up unless Larry is willing to go "all in" on this project (which he has no obligation to do).​

[hackmaster0110]

Is this project dead?