←back to thread

The first year of free-threaded Python

(labs.quansight.org)
253 points rbanffy | 2 comments | 16 May 25 09:42 UTC | HN request time: 0.006s | 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 #
amelius ◴[16 May 25 13:14 UTC] No.44005107[source]▶
Well, I think you can manipulate a dict from two different threads in Python, today, without any risk of segfaults.
replies(2): >>44005807 #>>44011904 #
1. pansa2 ◴[16 May 25 14:16 UTC] No.44005807[source]▶
You can do so in free-threaded Python too, right? The dict is still protected by a lock, but one that’s much more fine-grained than the GIL.
replies(1): >>44005911 #
2. amelius ◴[16 May 25 14:25 UTC] No.44005911[source]▶
Sounds good, yes.