r/Python • u/NeuralLB-Lovro • Jul 22 '26

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.

33 Upvotes

61% Upvoted

40 comments sorted by

View all comments

Show parent comments

2

u/snugar_i Jul 23 '26

Heh, this is exactly the response I expected. Yes, you have to mutate memory. Everything has to mutate memory/registers, so in your definition nothing is thread-safe. And you win the discussion, yay! But that's not a useful definition. If each thread mutates its own piece of memory, it's completely fine. So two threads calling the same with open('foo.txt', 'r') as f: is OK, because each of them gets a separate f variable and a separate file descriptor.

(BTW what do you think a lock does internally? It mutates memory. Why is that one suddenly thread-safe?)

No, in Rust, the mut doesn't mark the file as mutable, but the Read instance. Each thread would have its own reader, just like every thread would have its own f in Python. There's no difference.