Inside the Python GIL.
Why Stack Overflow recommends it
Stack Overflow users link it when explaining what the GIL is and why CPU-bound Python threads don't scale across cores.
Recommended by 2 people across 2 different months, 2009 to 2025.
What it is
A 2009 Chicago Python User's Group talk by David Beazley that digs into how CPython's Global Interpreter Lock works and how it behaves on multicore machines. It is a roughly one-hour recorded presentation, mirrored from the original blip.tv upload.
What people said
Strong rec klaas · 2016-12 · Stack Overflow · on “How do you determine if a function holds the GIL?”
As I understand it thats only relevant if you execute python threads. Every python thread is started as a native os thread on the system. But inside the python interpreter the running thread (only one) "holds" the GIL. Practically the current_thread pointer points at the thread. The GIL is relaesed mainly when the running thread calls an IO function (reading/writing files, sockets etc) then the GIL goes to the next thread, which can start running now ... ans so on. Check this (IMHO) very good overview from david beazley: [this video]
Recommends mztulip · 2025-01 · Stack Overflow · on “python main thread slow down with started second while loop thread”
After watching videos everything seems to be clear, my example is almost identical as presented in video. I also watched video form previous wrong link( [this video] ) . Thanks for this. I never thought about trying to find answer in youtube. Example with using event for waiting to exit seems nice. This solution have similarly long wait time to execute as with while loop. Sleep causes that it works fast. Also this is not my case when I need to check some values repeatedly, then making calculations. It works perfectly with sleep usage, but not with event.
Cites Vinay Sajip · 2009-08 · Stack Overflow · on “What is the global interpreter lock (GIL) in CPython?”
Python's GIL is intended to serialize access to interpreter internals from different threads. On multi-core systems, it means that multiple threads can't effectively make use of multiple cores. (If the GIL didn't lead to this problem, most people wouldn't care about the GIL - it's only being raised as an issue because of the increasing prevalence of multi-core systems.) If you want to understand it in detail, you can view this video [this video] or look at this set of slides [LINK] . It might be too much information, but then you did ask for details :-) Note that Python's GIL is only really an issue for CPython, the reference implementation. Jython and IronPython don't have a GIL. As a Python dev
Cites dstromberg · 2013-11 · Stack Overflow · on “Blocking cpu with semaphore in Linux possible? (Python)”
CPython doesn't deal well with CPU-bound threads on multicore systems, unless you disable all but one of your cores in your OS. Here's a presentation on the topic: [this video] CPython does fine for I/O bound, multithreaded workloads, but even one CPU-bound thread makes a mess of that on multicore. I recommend that you consider using multiprocessing instead of multithreading, unless you're purely I/O bound. That or use Jython or IronPython, which thread well.
Cites dstromberg · 2014-01 · Stack Overflow · on “concurrent.futures.ThreadPoolExecutor.map is slower than a for loop”
I've not yet tried futures, but I believe it's thread-based, so this probably applies: [this video] In short, I/O bound workloads thread well in CPython, but CPU-bound workloads do not. And if you mix I/O bound and CPU-bound threads in the same process, that doesn't thread well either. If that's the problem, I'd suggest increasing the size of your work chunks (just squaring a number is pretty small), and using multiprocessing [LINK] . Multiprocessing is thread-like, but it uses multiple processes with shared memory, and tends to give looser coupling between program components than threading anyway. That, or switch to Jython or IronPython; these reputedly thread well.
Cites Ijaz Ahmad · 2016-11 · Stack Overflow · on “What is the global interpreter lock (GIL) in CPython?”
Python doesn't allow multi-threading in the truest sense of the word. It has a multi-threading package but if you want to multi-thread to speed your code up, then it's usually not a good idea to use it. Python has a construct called the Global Interpreter Lock (GIL). [this video] The GIL makes sure that only one of your 'threads' can execute at any one time. A thread acquires the GIL, does a little work, then passes the GIL onto the next thread. This happens very quickly so to the human eye it may seem like your threads are executing in parallel, but they are really just taking turns using the same CPU core. All this GIL passing adds overhead to execution. This means that if you want to make your
Cites mike rodent · 2023-07 · Stack Overflow · on “Latency in detecting key press (hotkey) due to non-event-thread activity”
I think I finally detected the problem ... it's classic and it may be of interest to someone baffled by a similar situation. In my worker thread (non-event thread) I had multiple time.sleep(.0001) commands, the purpose of which is to allow other threads (including the event thread aka "main thread") to wrest control ... as previously explained here [LINK] by Musicamante in reply to an earlier question by me. The purpose of my worker thread, as mentioned, is to split apart Word (.docx) documents for analysis, using docx2python [LINK] , and the analysis itself is "CPU-intensive". I was slightly surprised to find that, even for a very large file, this command took very little time: docx_obj = d