GIL: not “Python can't do threads,” but “a thread waits exactly as long as you asked”

One microphone for the whole room

Picture a meeting. Eight people, one microphone, one rule: whoever holds the microphone speaks.

Nobody speaks slowly. Everyone says their sentence at ordinary speed. But eight sentences still take eight turns, not one — no matter how many people are sitting in the room.

That is the GIL. The microphone is the right to run Python code. The people are threads.

import threading
 
def crunch():
    x = 0
    for i in range(2_000_000):
        x += i * i
 
# two threads, each doing half of the work
t1 = threading.Thread(target=crunch)
t2 = threading.Thread(target=crunch)
t1.start(); t2.start()
t1.join();  t2.join()

On a two-core machine this code does not get faster. Measured: one thread — 0.1516 s, two threads — 0.1559 s. The second thread did not help; it got slightly in the way.

The rules for passing it on

The microphone is passed by the rules: roughly once every five milliseconds. This is not something the author made up, it is a setting you can see:

import sys
sys.getswitchinterval()      # 0.005

And it works predictably. If you put a “how long did I wait my turn” measurement in a loop, you get this:

Whatever you put in, that is roughly how long you wait. On the top two rows the miss is a few percent. On the bottom row it is larger — 0.72 instead of 0.5 — and the reason is clear: the more often the microphone is passed, the more noticeable the time of the passing itself.

And now the surprise

The rules apply between actions. There is nobody to take the microphone away in the middle of one action.

If the working thread has started something long — say, it sorted a list of two million elements — everyone else waits until it finishes. The setting stays the same, five milliseconds, and means nothing.

The difference is tens of times. And this is not a malfunction: it is written exactly that way in the CPython sources, next to the setting itself. It “encourages” a switch after the given time, but cannot enforce one, because a single action can last as long as it likes.

When the rule does not apply

This is the most important part, and it is usually lost behind the phrase “threads in Python are useless.”

While the program waits, it hands the microphone over. Downloading a page, querying a database, reading a file — all of that is waiting. Threads add up almost perfectly here:

import threading, time
 
def wait_a_bit():
    time.sleep(0.05)

Eight such waits in a row take 0.40 s. Eight threads take 0.05 s. Almost eight times faster, and no cores are needed for it: the threads are not computing anything, they are waiting.

Some libraries hand the microphone over too. While zlib is compressing, the interpreter is free. Measured: one thread compresses a buffer in 0.0564 s, two threads compress a buffer of the same size each — and finish in 0.0553 s. Twice the work, the same time.

From this comes a simple rule for choosing:

• the program waits — take threads, they work;
• the program computes inside a library that hands the microphone over — threads again;
• the program computes in pure Python — threads will not help, you need processes.

So was the GIL removed?

Partly, and not by default.

Since Python 3.13 there is a separate build compiled without the GIL. In 3.14 it became officially supported — but it did not become the one you get when you download Python from the site. The ordinary build still has the GIL, and the decision to change the default has been deferred to a separate future document that does not exist yet.

To check which build you have:

import sys
sys._is_gil_enabled()     # True in the ordinary build, False in the free-threaded one

In the free-threaded build the same counting code across two threads gave a speedup of ×1.76 on two cores. Not ×2 — freedom has a price: this build is slower on its own, and on tight loops the difference reached 14–46%.

And there is an unpleasant detail worth knowing in advance: if two threads read the same objects, in the free-threaded build they start getting in each other's way. Measured across four runs: together they come out at ×0.45–0.52, that is, slower than alone, with twice the work. In the ordinary build the same runs give ×0.94–1.00 — no gain, but no loss either: the threads simply stand in the queue.

So “let's remove the GIL and it will get faster” does not work as a plan. Something else does: understand what your program waits for and what it computes.

Why know this?

Because the GIL comes up in interviews, and the right answer there is usually wrong.

“The global interpreter lock keeps threads from running in parallel, so CPU-bound work needs multiprocessing” is a memorized formula, not understanding. It does not explain why requests works perfectly well across twenty threads, why numpy computes on every core, and why your web server sometimes produces responses of a hundred or two hundred milliseconds out of nowhere — when there is nothing there that takes that long to compute.

Below are four things, each of them taken off a running interpreter:

1. what sys.setswitchinterval affects (the answer is more direct than it looks);
2. when that setting affects nothing at all;
3. the cases where the GIL takes no part in what is happening;
4. what exactly changed with free-threaded builds — and what did not.

All timings were taken on CPython 3.13.7, in two builds of the same patch release: the ordinary one and one built with --disable-gil (the single exception is the table of getswitchinterval() values below, which comes from six different builds). Machine: Linux x86_64, 2 cores. Two cores is an important detail: every “speedup” below hits a ceiling of ×2, and nowhere do I pass that off as a general law.

The mental model

A meeting in a conference room. Many people, one microphone, and the rule is simple: whoever holds the microphone speaks.

This is not “people speak slowly.” Everyone speaks at ordinary speed. But if eight people each need to say one sentence, eight sentences take eight turns, not one — no matter how many chairs the room has.

The rule has three consequences, and all three are testable:

• There are rules of order. The microphone changes hands roughly once every five milliseconds. “Roughly” is the operative word: there is an agreement, there is no enforcement.
• There is an exception. While a person is not speaking but listening, or digging a piece of paper out of a bag, they hand the microphone over. Waiting does not hold the queue.
• There is a hole in the rules. If someone starts reading a long document aloud, there is nobody to take the microphone away mid-paragraph. The rules say “five milliseconds,” reality says “until they finish reading.”

The rest of the article is these three consequences translated into numbers.

What the GIL literally is

The definition in the Python glossary describes a mechanism, not a metaphor: it is the means by which the CPython interpreter ensures that only one thread executes bytecode at a time. The same entry says why: it makes the object model, including types such as dict, implicitly safe against concurrent access.

And that same glossary paragraph carries two caveats that usually get skipped:

• some extension modules are “designed so as to release the GIL when doing computationally intensive tasks such as compression or hashing”;
• “the GIL is always released when doing I/O”.

That is, half of the claim “Python can't do parallelism” is refuted inside the definition of the GIL itself. We will come back to this in the third section.

The switching itself lives in Python/ceval_gil.c. So does the constant:

#define DEFAULT_INTERVAL 5000

Five thousand microseconds, that is, 5 ms. This is exactly the value sys.getswitchinterval() returns, and it is the same in every build checked:

The last row deserves a separate look: in a build where the GIL is off, the setting for the GIL switch interval still exists and still returns five milliseconds. Whether it affects anything there is a question with a measured answer below.

First: the interval works literally

Let's run the experiment that answers the question “what does setswitchinterval actually change.”

Two threads. The first is “greedy”: it computes in a loop and never gives up the interpreter voluntarily. The second is “quick”: in a loop it calls time.sleep(0), that is, yields control and immediately asks for it back, and records how much time passed. What it records is the time spent waiting its turn.

def probe():
    while not stop.is_set():
        t0 = time.perf_counter()
        time.sleep(0)                     # release the GIL and ask for it back
        lags.append((time.perf_counter() - t0) * 1000)

The first three columns show a relationship visible without any statistics:

At 5 and 50 ms the median diverges from the setting by a few percent: +5.6% and +0.67%. At 0.5 ms the divergence is already +43% — and that too is a result, not measurement error: the more often control changes hands, the larger the share of the timeslice the handoff itself takes. The setting defines a lower bound on the wait, not an exact value.

From this follows a practical conclusion that is rarely stated outright: the GIL does not take CPU time away from you — it adds latency. If you have a threaded web server and one endpoint computes something heavy in pure Python, every other request picks up an addition to its latency on the order of the switch interval. The CPU may be idle the whole time.

The same thing is visible from the other side — if you look not at waiting but at holding.

The median holding stretch at the default interval is 5.127 ms. The match with the setting is almost literal.

But the same window contains a stretch 10.3 ms long — two timeslices in a row. And that is not measurement error, it is the entrance to the second part of the story.

Second: the interval guarantees nothing

Next to DEFAULT_INTERVAL in the source there is a caveat worth reading in full: the mechanism “encourages a defined switching period, but doesn't enforce it since opcodes can take an arbitrary time to execute”.

Encourages, but does not enforce — because a single operation can run for arbitrarily long.

The sys.setswitchinterval documentation says the same thing in different words: the value sets the ideal duration of a timeslice, the “actual value can be higher, especially if long-running internal functions or methods are used”, and — in a sentence of its own — “The interpreter doesn't have its own scheduler”.

Let's check. Same experiment, same 5 ms interval, but the greedy thread now performs not a million short operations but one long one:

A = 7 ** 500_000        # 1,403,678 bits
B = 11 ** 500_000       # 1,729,716 bits
 
def one_big_mul():
    A * B               # one operation, nowhere to interrupt it

The median of the third row is thirty-five times the median of the first. The worst sample in that same row is 379.826 ms, that is, seventy-six times the configured interval of 5 ms. The interval itself was never changed.

The mechanism here is simple, and that is what makes it unpleasant. The request to hand over control is raised as a flag, and the flag is checked by the interpreter loop — between operations. Inside a single operation there is nobody to check it: sorted() goes into C code and returns from there when it is done. There is no “preemptive multitasking” at this level, and sys.setswitchinterval does not add any.

The practical trace of this observation: if somewhere in your threaded server there is a sorted() over a large list, a regular expression over a megabyte of text, or arithmetic on big integers, lowering switchinterval will not help. The only thing that helps is moving it out of the thread: into a process, into a queue, into a library that releases the GIL.

Third: when the GIL has nothing to do with it

Now to the caveats from the glossary. Three kinds of work, two builds, the same code.

This table is worth reading by rows, not by columns.

Pure Python — ×0.97. Two threads did the same work in the same time — more precisely, almost three percent slower: switches are not free. This is the only row for which the phrase “the GIL gets in the way of threads” exists.

Waiting — ×7.86. Eight time.sleep(0.05) calls in sequence take 0.4016 s, eight threads take 0.0511 s. Zero cores are needed for this: the threads are not computing, they are waiting, and for the duration of the wait the GIL is released. This is exactly why “Python can't do threads” never stopped anyone from downloading a hundred pages at once.

zlib.compress — ×2.04. The comparison here is set up differently, and that matters: one thread compresses a 5,999,872-byte buffer in 0.0564 s, two threads compress a buffer of the same size each — and finish in 0.0553 s. Twice the work, the same time. Both cores are busy, and the GIL is held by nobody.

Why this works is written in the C API documentation. The Py_BEGIN_ALLOW_THREADS macro expands to

{ PyThreadState *_save; _save = PyEval_SaveThread();

and its counterpart Py_END_ALLOW_THREADS expands to PyEval_RestoreThread(_save); }. Between them, C code runs without holding the interpreter. The documentation even names specific modules: “the standard zlib and hashlib modules detach the thread state when compressing or hashing data”.

From this follows a rule worth keeping in mind when choosing a library: the question is not “is it Python or C” but “does this function release the GIL”. A C extension that honestly computes while holding the GIL is no better for threads than pure Python — it is simply faster on one thread.

Free threading: what is already true

It is easy to overdo this in either direction, so: by dates and by documents.

PEP 703, Sam Gross, status Final, decision October 24, 2023, Python 3.13. Adds the --disable-gil build flag and states the boundary outright: “The global interpreter lock will remain the default for CPython builds and python.org downloads”. That is, the very PEP that “removes the GIL” says the GIL remains the default.

PEP 779, Thomas Wouters, Matt Page and Sam Gross, status Final, decision June 16, 2025, Python 3.14. This is Phase II: the free-threaded build is officially supported, but still optional. In the What's New sections for 3.14 this is recorded in one line: “PEP 779: Free-threaded Python is officially supported”.

Phase III — making the free-threaded build the default — has not happened. PEP 779 says so itself: the decision is “very different, and we expect it will revolve around community support, willingness, and showing clear benefit. That's left for a future PEP”. At the time of writing there is no such PEP.

What is happening right now: 3.15 is at the release-candidate stage (rc1 came out August 4, 2026, the final is scheduled for October 1), and the changes there are about tooling, not about changing the default: PEP 803 adds a stable ABI for free-threaded builds (abi3t), the profiler gains a --mode gil option, and the PyGILState_* family has been soft-deprecated — with no plans for removal and with existing code kept working.

You can check where you are from the interpreter itself:

import sys, sysconfig
 
sys._is_gil_enabled()                        # False in a free-threaded build
sysconfig.get_config_var("Py_GIL_DISABLED")  # 1 in a free-threaded build, 0 in the ordinary one
sys.abiflags                                 # "t" in a free-threaded build

And — the promised answer to the question from the first section: what sys.setswitchinterval does in a build where the GIL is off. The answer is nothing. The same wait measurement, three different intervals:

Three identical values in the right column are the substantive result. The setting survived, returns the same 0.005, and does not affect behavior: the queue whose length it governed no longer exists. The remaining 0.067 ms is the cost of time.sleep(0) itself and of the OS scheduler, not a wait for anything inside the interpreter.

One more detail worth knowing in advance: the free-threaded build can turn the GIL back on. The PYTHON_GIL=1 variable or the -X gil=1 option brings it back. Verified: PYTHON_GIL=1 python3.13t -c "import sys; print(sys._is_gil_enabled())" prints True. This is not a curiosity — it is how the free-threaded build lives with extensions that are not ready for it.

What the free-threaded build costs

This is where it is easy to lie with a number, so: first the source, then my measurements, then an explanation of the discrepancy.

The official HOWTO names the price outright: “The free-threaded build has additional overhead when executing Python code compared to the default GIL-enabled build”, and then the range on the pyperformance suite: “from about 1% on macOS aarch64 to 8% on x86-64 Linux systems”.

My measurements came out higher:

This is not a refutation of the official figure, and presenting it as “the overhead is actually 46%” would be a lie. The difference is explained by what was measured: pyperformance is a set of heterogeneous programs where the interpreter is busy with more than executing bytecode. My two tests are tight loops made up of exactly the operations that got more expensive in the free-threaded build. This is the worst case, not the average.

The correct phrasing sounds duller and is more useful: the price depends on what the program is doing, and on tight pure bytecode it is noticeably above the benchmark average.

In exchange, the free-threaded build gives something that never happens with the GIL at all: on the same two cores, pure Python across two threads gave ×1.76. Not ×2 — part of it is eaten by the same price as in the table above, plus the machine has two cores and something else is running on it.

The non-obvious part of the price

This part is not written in the documentation, and it does not get asked in interviews.

PEP 703 uses biased reference counting — an approach that rests on the observation that “most objects are only accessed by a single thread, even in multi-threaded programs”. An object has an owning thread, and reference-count operations from that thread take the fast path, while those from another thread take the shared one.

Let's check whether this is visible from the outside. The experiment is deliberately arranged so that there is no contention at all: there is exactly one worker thread. Only the origin of the data changes.

FOREIGN = make(0)                 # list created on the main thread
 
def worker_reads_foreign():
    loop(FOREIGN, 3_000_000)      # the objects are owned by another thread
 
def worker_reads_own():
    items = make(2)               # list created right here
    loop(items, 3_000_000)

In the GIL build there is no difference — 1.2% is noise. In the free-threaded build, reading foreign objects costs 15.4% more, even though there is no second thread and nobody to contend with.

And if a second thread does appear and both read the same objects, this is what happens: two threads doing 2,000,000 accesses each completed the work in 0.6108 s against 0.1376 s for a single thread. That is, the two of them together are slower than one, and with twice the work the result is ×0.45. Across four runs it is ×0.45–0.52.

The same pair of measurements in the GIL build gives ×0.94–1.00 across the same four runs. The spread here is larger than the effect itself, and that is precisely the answer: with the GIL, two threads on shared objects win nothing, but lose nothing either — they simply stand in the queue.

There is one practical conclusion from these three rows, and it is not about the GIL: in a free-threaded build it matters who created an object and who touches it. State shared between threads goes from “awkward” to “expensive”, and “let's just run it on the free-threaded build and get a speedup” does not work as a strategy.

What to do about it

A short map of decisions, each tied to something measured above.

The work is waiting (network, disk, database). Threads already work, and have for a long time. Measured ×7.86 across eight waits. The GIL takes no part here. The free-threaded build adds nothing: ×7.74, the same within measurement error.

The work is heavy computation inside a library. Check whether it releases the GIL. zlib and hashlib do, and that is written in the documentation; for the rest, look at the scaling, as in the table above. If it releases the GIL, threads will give a speedup across cores with no free-threaded build at all.

The work is pure Python, and there is a lot of it. Processes (multiprocessing, concurrent.futures.ProcessPoolExecutor) have remained the working answer since 2008. The free-threaded build is the second answer, now officially supported, but with the caveats from the previous section.

The problem is latency, not throughput. This is where sys.setswitchinterval makes sense, and the table at the start of the article shows exactly what you buy and what you pay: reducing the interval tenfold cut the median wait by a factor of 7.4 (5.279 → 0.717 ms) and increased the number of switches by the same factor (283 → 2026 samples in the same time). Not tenfold — part of the gain is eaten by the handoff itself. But if the latency is created by one long operation, the setting is useless — that is section two.

And in general. It is more useful to think of the GIL not as “a limitation of Python” but as an explicit queue that has a setting. The queue is visible, it is measured in three lines of code, and it behaves predictably right up to a boundary that is also documented — in the comment next to the constant that sets the interval.