←back to thread

The first year of free-threaded Python

(labs.quansight.org)
256 points rbanffy | 1 comments | 16 May 25 09:42 UTC | HN request time: 0.228s | source
Show context
AlexanderDhoore ◴[16 May 25 11:03 UTC] No.44003888[source]▶
Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.
replies(19): >>44003924 #>>44003936 #>>44003940 #>>44003943 #>>44003945 #>>44003958 #>>44003971 #>>44004203 #>>44004251 #>>44004431 #>>44004501 #>>44005012 #>>44005100 #>>44005259 #>>44005773 #>>44006165 #>>44007388 #>>44011009 #>>44011917 #
bratao ◴[16 May 25 13:05 UTC] No.44005012[source]▶
This is a common mistake and very badly communicated. The GIL do not make the Python code thread-safe. It only protect the internal CPython state. Multi-threaded Python code is not thread-safe today.
replies(3): >>44005107 #>>44005204 #>>44007726 #
1. kevingadd ◴[16 May 25 17:09 UTC] No.44007726[source]▶
This should not have been downvoted. It's true that the GIL does not make python code thread-safe implicitly, you have to either construct your code carefully to be atomic (based on knowledge of how the GIL works) or make use of mutexes, semaphores, etc. It's just memory-safe and can still have races etc.