3 ms·
The opposite, writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself that the GIL previously avoided. But,
by dpedu 3y ago
The opposite, writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself that the GIL previously avoided. But, the tradeoff is that multithreaded programs could now actually achieve multithreaded performance gains.
- bvrmn 3y agoA single Go thread still replaces 10 Python threads, speaking very roughly. It's a quite particular narrow set of problems noGIL would solve.
- sapiogram 3y agoLooks like ML workloads is the primary use case here, no amount of goroutines will help you there as long as the ecosystem doesn't exist.
- Jtsummers 3y ago> writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself I'd phrase this differently: Writing correct multithreaded code will be just as challenging (or not, depending on the person and their comfort with concurrent and parallel code development) as before, but now you won't be able to get away with sloppy multithreaded code that relied on the GIL to not break.
- fbdab103 3y agoIt was correctly written to the invariant promises of the platform at the time. If Python is altering the deal, that does not suddenly make the library writer at fault.
- oivey 3y agoThere seems to be some confusion here. The GIL is not an invariant of Python that makes your code thread safe. Python is not altering the deal. You can still use threads to write concurrent code in Python today, and you'll still run into all of the classic concurrency related bugs. People just mostly don't bother writing threaded code in Python today because it provides no performance benefit. That may change, and it very likely will expose many threading bugs that already exist in many libraries that just have never been found.
- dpedu 3y agoYou're right, the GIL certainly doesn't automatically make all code thread-safe. However, it does make some operations that would normally be problematic in a multithreaded context thread-safe. Such as: appending to a list, updating a dict, modifying object attributes, and others. https://docs.python.org/3/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe https://docs.python.org/3/faq/library.html#what-kinds-of-glo...
- angus_gh 3y agoThe no-gil fork of Python makes the builtin collections thread-safe, so that will remain not an issue (see the "Collection thread-safety" section of the design doc https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit?usp=drivesdk https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... )
- School-Cotton 3y agoWhy do you say code relying on the GIL is incorrect? The GIL is a documented part of Python.