Re:A viable solution for Python concurrency
by BiteCode_dev on Friday October 15, 2021 @04:26PM
(#28882760)
It 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.
Re:A viable solution for Python concurrency
by azinman2 on Friday October 15, 2021 @06:59PM
(#28884114)
This entire article is about removing the GIL
Re:A viable solution for Python concurrency
by heavyset_go on Friday October 15, 2021 @04:07PM
(#28882526)
I 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.
Re:A viable solution for Python concurrency
by bonzini on Friday October 15, 2021 @04:02PM
(#28882460)
In 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.
Re:A viable solution for Python concurrency
by yellowapple on Friday October 15, 2021 @06:59PM
(#28884112)
It'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.
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.