3 ms·

there's a lot of code I wrote (and saw people write) in Python over the years, conscious that noone will ever run it in threads (ofc it's possible, but typicall

there's a lot of code I wrote (and saw people write) in Python over the years, conscious that noone will ever run it in threads (ofc it's possible, but typically pointless), thus going quite easy on things that wouldn't be thread-safe. this used to quite a comfortable stance. community ended up inventing other ways to share state, other ways to vectorize, other ways to avoid blocking on I/O, that might sometimes be annoying, but evolved to be quite reasonable for Python. giving up this stance? a lot of code is instantly a legacy, and a lot of it is a legacy people won't even know about before they notice the problems. and for what? i must say that i have no experience running Python without GIL so my idea of the ways things can be not thread-safe is purely speculative/borrowed from very different languages (that I finally moved on to long ago, thank god). so maybe i'm wrong, i misunderstand the impact, and all this code is just fine

miraculixx 3y ago
Well said. Thanks
valyagolev 3y ago
people in this thread mention that, for some reason, "even with GIL you still have to write thread-safe code", which is an admirable stance, but I don't think many people do it, because their webserver or whatever uses the many single-threaded processes model and they don't want to waste time on that
- miraculixx 3y ago
  Indeed. And the reason they use multiprocessing is bc they have learned that Python's multithreading is not a good option in cpu bound tasks. The blessing in disguise of course being that multiprocessing is also a shared nothing model, so (mostly) lock free programming is the default. Oth if you have a need for concurrently accessed shared memory/resources and need locks, it comes with an explicit cost. I think that's a good thing. In the future the default concurrency model will be shared everything free threading, and all hell might break loose. Hopefully not.
  - valyagolev 3y ago
    IMO Python doesn't even offer enough in the way of good synchronisation primitives for the async code. I don't think the ecosystem is ready for this one. I hope it'll be recognised by the most "host" applications (uvicorn or whatever) that multi-threading is not a good idea anyway and they'll discourage it. But there'll definitely be a macho-land of thread-"safe" programmers whose bugs we'll be downstream of

miraculixx 3y ago

Well said. Thanks

valyagolev 3y ago

people in this thread mention that, for some reason, "even with GIL you still have to write thread-safe code", which is an admirable stance, but I don't think many people do it, because their webserver or whatever uses the many single-threaded processes model and they don't want to waste time on that

miraculixx 3y ago
Indeed. And the reason they use multiprocessing is bc they have learned that Python's multithreading is not a good option in cpu bound tasks. The blessing in disguise of course being that multiprocessing is also a shared nothing model, so (mostly) lock free programming is the default. Oth if you have a need for concurrently accessed shared memory/resources and need locks, it comes with an explicit cost. I think that's a good thing. In the future the default concurrency model will be shared everything free threading, and all hell might break loose. Hopefully not.
- valyagolev 3y ago
  IMO Python doesn't even offer enough in the way of good synchronisation primitives for the async code. I don't think the ecosystem is ready for this one. I hope it'll be recognised by the most "host" applications (uvicorn or whatever) that multi-threading is not a good idea anyway and they'll discourage it. But there'll definitely be a macho-land of thread-"safe" programmers whose bugs we'll be downstream of