https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
In particular, the design document's observation that "some C API extensions need modifications to protect global data structures that were previously protected by the GIL" serves as a direct confirmation that this change was not able to avoid breaking at least some multithreaded code that relies on the GIL to provide thread safety.
Yes, C extensions that count on the GIL for handling their own internal locking will obviously need updates.
> To mitigate compatibility issues and improve debugging, the proof of concept can run with the GIL enabled or disabled controlled at runtime by an environment variable (or command-line option). If CPython adopts some form of the GIL changes, I’d expect this runtime control to be useful for at least a few releases to address flag day issues.
This doesn't say "GILectomy will forever remain an opt-in".
The socketserver.BaseServer class sets self.__shutdown_request in one thread and expects it to be picked up by another. In the Java memory model this variable would have to be marked as volatile (or the methods involved as synchronized) to make sure that the other thread will actually see the change, so unless Python implicitly make every variable volatile (does it?) this wouldn't be guaranteed to work (although it would probably mostly still work most of the time except for when it mysteriously doesn't).
The nogil development uses biased reference counting, with an atomic lock between threads, and doesn't change that behavior.
As I understand it, a different thread running on a different core could have a cached version of a value which wouldn't necessarily be updated unless some instruction is issued to synchronize with main memory, which in Java is done with volatile or synchronized.
Also, if some optimization is implemented that reorders instructions or eliminates the variable update entirely, that could also prevent the other thread from ever seeing the updated value. This is also solved by using volatile or sychronized in Java.
Is every variable implicitly volatile in nogil Python? Or only object attributes? Or have I completely misunderstood some important aspect?
Edit: I suppose modifying the reference count might cause implicit synchronization similar to the piggybacking technique [1] in Java, making this a non-issue?
That said, I am not a good source for truth on this. But it feels like so much code would break if this weren't true that I don't think it would have gotten to this stage.
FWIW, here's the primary description of how it works - https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... .
Here's a patch the author himself wrote to fix a spot where this change break's numpy's thread safety: https://github.com/colesbury/numpy/commit/2ad41a1fb8b0c28fa8...
Maybe that's the only one? Maybe it isn't? But I think the point still stands that people saying this has the potential to break existing Python packages in subtle ways are not just being hyperbolic.