4 ms·
Concurrency is impossible to prove sound without language-level guarantees. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf https://www2.eecs
by rectang 5y ago
Concurrency is impossible to prove sound without language-level guarantees.
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...
I'm astounded that a change which will release untold heisenbugs into the wild is being considered. It changes my view of Python. In terms of inducing subtle, silent breakage in existing code, it reminds me of this horrifying change from PHP 8:
https://www.php.net/manual/en/migration80.incompatible.php#migration80.incompatible.core.string-number-comparision https://www.php.net/manual/en/migration80.incompatible.php#m...
- da39a3ee 5y agoHowever it, err, looks like some things did need fixing in PHP v7.
- drothlis 5y ago> The GIL will still be optionally available as an interpreter startup-time option Sounds like they’re going to make it opt-in (or opt-outable) if they do merge it.
- mijoharas 5y ago> it reminds me of this horrifying change from PHP 8 The only thing horrifying to me is that that behaviour was there in the first place! I would be 100% behind those fixes, I assume from your response that you would not do them in the sake of backwards compatibility. What would be your solution? To always have these idiosyncrasies in the language, or did you have a problem with how the fixes were implemented or rolled out?
- rbanffy 5y ago> Concurrency is impossible to prove sound without language-level guarantees. Not sure I understand that. The proposal is not to simply get rid of the GIL, but to have a two-tier mechanism that ensures correctness with all the C source that uses the macros it should use and doesn’t mess with refcounts behind Python’s back (doing sketchy stuff usually ends up in pain)
- AlphaSite 5y agoIsn’t this an option change. this Gil still exists in theory iirc.