3 ms·
There 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 us
by oivey 3y ago
There 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... )