3 ms·
I'd wonder if it would be easier to introduce a totally new API along the lines of ruby's ractor API[1] that enables thread parallelism while keeping existing T
by dangerbird2 5y ago
I'd wonder if it would be easier to introduce a totally new API along the lines of ruby's ractor API[1] that enables thread parallelism while keeping existing Thread behavior identical as with the GIL. Tons of python code relies on threaded code that is thread-safe under the GIL, but would completely blow up if the GIL was naively replaced.
[1] https://docs.ruby-lang.org/en/master/doc/ractor_md.html https://docs.ruby-lang.org/en/master/doc/ractor_md.html
- arthurcolle 5y agoRactors don't offer very good performance yet. Better to have it be awesome right off the bat
- dangerbird2 5y agoYeah, That's what I thought. I think the greatest barrier now is that most multithreaded python code right now is just barely thread-safe, even with the GIL. I occasionally have to remind colleagues that even though the GIL guarantees instructions are atomic, you need to use mutexes and other synchronization primitives to ensure there is no race condition between multiple instructions. I'd imagine this change would be an optional interpreter feature initially, since removing the GIL would break the vast majority of code out in the wild, and it would be much more difficult to create an automated conversion tool like they did with the syntactic changes between 2.7 and 3