4 ms·
asyncio is not a competition to threads, it's complementary. In fact, it's a perfectly viable strat in python to have several processes, each having several th
by BiteCode_dev 5y ago
asyncio is not a competition to threads, it's complementary.
In fact, it's a perfectly viable strat in python to have several processes, each having several threads, each having an event loop.
And it will still be so, once this comes out. You will certainly use threads more, and processes less, but replacing 1000000 coroutines by 1000000 system threads is not necessarily the right strategy for your task. See nginx vs apache.
- dralley 5y agoMultiple threads with one asyncio loop per thread would be absolutely pointless in Python, because of the GIL. With that said, sure, threads and asyncio are complimentary in the sense that you can run tasks on threadpool executors and treat them as if they were coroutines on an event loop. But that serves no purpose unless you're trying to do blocking IO without blocking your whole process.
- bonzini 5y agoIn Python it would be pointless, but for example it's how Seastar/ScyllaDB work: each thread is bound to a CPU on the host and has its own reactor (event loop) with coroutines on it. QEMU has a similar design.
- yellowapple 5y agoIt's also (to my knowledge) how Erlang's VMs (e.g. BEAM) work: one thread per CPU core, and a VM on each thread preemptively switching between processes.
- heavyset_go 5y agoI read it as each process having multiple threads and an event loop. If the threads are performing I/O or calling out to compiled code and releasing the GIL, said GIL won't block the event loop.
- BiteCode_dev 5y agoIt would not be pointless at all, because while one thread may lock on CPU, context switching will let another one deal with IO. This can let you smooth out the progress of each part of your program, and can be useful for workload when you don't want anything to block for too long.
- azinman2 5y agoThis entire article is about removing the GIL
- Zarathust 5y ago"Viable" as in "you have no other choice sometimes". This forces you to deal with 3 libraries each with their own quirks, pitfalls and incompatibilities. Sometimes you even deal with dependencies reimplementing some parts in a 4th or 5th library to deal with shortcomings. I really don't care that much which of them survive, I just want to rely on less of them
- BiteCode_dev 5y agoNo, it's just useful. They are techs with different trade off, and life is full of opportunities.
- throwaway81523 5y agoPython Zen = one obvious way to do it. Having a bunch of very different ones, each with serious disadvantages, is a bad look.
- heavyset_go 5y agoZen of Python is an ideal, and at this point, kind of tongue-in-cheek. This is the same language that shipped with at least 3 different methods to apply functions across iterables when the Zen of Python was adopted as a PEP in 2004.
- throwaway81523 5y agoThere is at least some recognition in those cases that they introduced the new thing because they got it wrong in the old thing. That's different than saying they should co-exist on equal terms.
- heavyset_go 5y ago> That's different than saying they should co-exist on equal terms. I'm not sure who is claiming that. Here's the OP we're replying to: > They are techs with different trade off, and life is full of opportunities.