
Latency in Asynchronous Python - chmaynard
https://nullprogram.com/blog/2020/05/24/
======
qq11ww22ee33
> 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.

------
thehesiod
I wrote and use
[https://github.com/CaliDog/asyncpool](https://github.com/CaliDog/asyncpool)
(CaliDog graciously created a module of it for me) to solve this issue. Here
it is forked on my repo:
[https://github.com/thehesiod/asyncpool](https://github.com/thehesiod/asyncpool)

------
erdewit

        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.

------
xapata
I think the curio project addresses some of these asyncio design concerns.

~~~
j88439h84
How so?

~~~
xapata
[https://vorpus.org/blog/some-thoughts-on-asynchronous-api-
de...](https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-
post-asyncawait-world/)

