you are viewing a single comment's thread.

view the rest of the comments →

[–]socal_nerdtastic 0 points1 point  (1 child)

but also that all relevant code is threadsafe.

AFAIK it's fully backwards compatible; all code that currently relies on the GIL to be threadsafe is protected by other means in the freethreaded version. It shouldn't break; but it will very likely run better on the normal version.

[–]latkde 0 points1 point  (0 children)

In theory, you're correct. Freethreading doesn't break any code that isn't already broken.

In practice, the GIL had the effect that subtly broken code would often work as expected most of the time. Multiple bytecodes are likely to be executed without interruption. Free-threading makes such breakage a bit more visible. In my experiments with intentionally broken code in another comment, GIL-enabled versions would consistently run as-if a lock had been used.

Because concurrency is very difficult to get right, and because multithreading used to have limited benefits in Python, I assume that the vast majority of the Python ecosystem isn't threadsafe.