3 ms·
It would be helpful and interesting if you could explain why the impact is so huge
by floomk 3y ago
It would be helpful and interesting if you could explain why the impact is so huge
- gary_0 3y agoThey're talking about C code that blindly relies on implicit concurrency guarantees that are now conditional. Isn't that enough said?
- mrlyx 3y agoNot at all. The GIL was explicitly part of the C-API! No one used the guarantees accidentally, including CPython itself. The GIL was one of the reasons why the C module ecosytem took off.
- gary_0 3y agoThat's not the implicitness I'm talking about. While it sounds like loading old C modules will just re-enable the GIL, the problem is that they will never be updated to not rely on the old Python concurrency model. All that C code was written implicitly assuming that certain blocks of code were surrounded by a GIL. It could be a real headache for any hoped-for transition to nogil Python if lots of GIL-reliant C code is floating around where there's little hope of updating it without having to worry about subtle bugs popping up. And even if the conversion was risk-free (which I doubt), many organizations will still not want to dig into their legacy C codebases and make significant changes.
- lanstin 3y agoAnd the probability of a given piece of C code that was written for a thread safe environment working when called from multiple threads at once is pretty low for anything not 100% purely functional.
- CJefferson 3y agoHonestly, that’s not my biggest worry. My bigger worry is that now Python variables your extension is reading can be changed by another thread in real time. Before if you held the GIL, you knew nothing would change while you poked some Python datastructures.