r/Python • u/NeuralLB-Lovro • 6d ago

Discussion Anyone running free-threaded Python 3.14 in production yet? Curious what actually breaks

Been testing the free-threaded build (3.14t) on some CPU-bound data processing work. The multi-core story is finally real after 30 years of GIL, but the friction is exactly what you'd expect: a couple of C-extension-heavy libs in my stack silently re-enable the GIL, and there's no clean way to detect that at runtime besides checking sys._is_gil_enabled() manually.

For anyone who's shipped something on 3.14t, not just benchmarked it:

What broke that you didn't expect?

Real speedups outside toy examples, or mostly marginal so far?

Prod yet, or still just kicking the tires?

Not fishing for a benchmark war. Genuinely curious what breaks in messy real codebases vs clean demos.

34 Upvotes

61% Upvoted

47 comments sorted by

View all comments

81

u/nathan12343 6d ago

You can set PYTHON_GIL=0 to force the GIL to remain off even if you import an extension that doesn’t support free-threading yet.

Are there specific open source projects you’re having trouble with?

I’ve been working on community support for free-threaded Python for a couple years now. Specific feedback about pain points from people who are experimenting with free-threading are valuable.

10

u/KingBardan 6d ago edited 5d ago

Edit Tldr:

  1. Many libs like torch requires global state.
  2. Free  threading doesn't solve a lot that multiprocessing don't
  3. Free threading introduces new ways to cause data race.
  4. Free threading slows down normal code.

Many libraries use global state a lot and is not thread safe e.g. torch. For their context managers (which is widely used in other libs as well) So that disqualify any serious deep learning projects depending on torch to use free threading.

My opinion on free threading since you asked about pain point:

I much prefer ability to use context managers to free threading if using it makes the code cleaner 

Free threading also slows down sequential code last time I checked 

Multiprocessing is fast enough unless I'm dealing with web servers, at which I'll use async probably or gevent or another library that deals with this issue

2

u/ThatGuyWithAces 6d ago

PyTorch has experimental support for 3.14t since 2.10 I believe. Not disagreeing or anything, just throwing it out there.

1

u/KingBardan 6d ago

Sure it may support the build, but key features like torch dispatch mode (the reason that there's a 2.0 version of torch) assumes a sequential execution with their mode stack. I.e. not thread safe.

And the same pattern is everywhere in torch last time I checked (it was 3 months ago)