> Never, ever use unbounded queues. In fact every unbounded asyncio.Queue() is a bug. It’s a serious API defect that asyncio allows unbounded queues to be created at all.
asyncio is very poorly designed overall. This is just one offender.
> asyncio.sleep(0) is nearly always wrong.
This, however, is VERY bad advice. a sleep(0) (or, a checkpoint as it is better called) is very useful in things like branches where asynchronous operations only run in one branch. This ensures you don't end up deadlocking half your app if your branches go wrong.
async def process():
time.sleep(JOB_DURATION) # simulate CPU time
This is synchronous (blocking) code, so if that is scheduled all at once that will block the event loop and make the heartbeat late. It's first come first served cooperative concurrency after all.
A better solution is to make the CPU intensive code cooperative by running it in a different thread or process.
> Never, ever use unbounded queues.
Hmm... I rather like them. But the consumers must be able to keep up with the producers or their must be some form of back pressure.
6 comments
[ 3.7 ms ] story [ 25.0 ms ] threadasyncio is very poorly designed overall. This is just one offender.
> asyncio.sleep(0) is nearly always wrong.
This, however, is VERY bad advice. a sleep(0) (or, a checkpoint as it is better called) is very useful in things like branches where asynchronous operations only run in one branch. This ensures you don't end up deadlocking half your app if your branches go wrong.
A better solution is to make the CPU intensive code cooperative by running it in a different thread or process.
> Never, ever use unbounded queues.
Hmm... I rather like them. But the consumers must be able to keep up with the producers or their must be some form of back pressure.