3 ms·
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 m
by 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 agoIndeed. 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 agoIMO 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