econchick / mayhem

The Python asyncio tutorial I wish existed earlier

Tutorial code for "asyncio: we did it wrong"

This repo is an accompaniment to my talk titled Advanced asyncio: Solving Real-World Production Problems at EuroPython 2019 in Basel, Switzerland; PyCon US 2019 in Cleveland, OH; EuroPython 2018 in Edinburgh, Scotland; and for PiterPy in St. Petersburg, Russia in November 2018.

Follow along at https://roguelynn.com/words/asyncio-we-did-it-wrong/

Talk recording can be found here and slides here.

mayhem's Issues

Some points may need reconsideration

I’m reading this tutorial right now, particularly the second part. I like it overall, but I believe some things might be not entirely correct. Even though this tutorial is 4 years old, it's still valuable as there are not many advanced asyncio tutorials around the web. I believe it deserves some discussion.

I'm concerned with that part, where the author says that one of the first examples of the Mayhem service is blocking.

“We are essentially blocking ourselves; first we produce all the messages, one by one. Then we consume them, one by one.”

The author also presents a synchronous example and says it’s equivalent to the async one (in the sense that they’re both non-concurrent). Then she suggests wrapping every await queue.put(msg) in a separate task to make it really concurrent.

1. Wrapping every queue.put(msg) with a task is not what makes this example actually concurrent. In fact, it's a short sleep inside the for loop. If you only add a sleep call, the producer and the consumer will start working concurrently (because they are two separate coroutines created with create_task in the first place). As far as I understand from looking at the source code, await queue.put(msg) does not yield control to the event loop, unless the queue is full. If the queue has free slots, this method delegates to put_nowait, which is a regular sync method. This gives no time to the consumer coroutine to do any work. In the meantime, if you add a sleep to the sync example, nothing will change, it will indeed produce all the messages and only then consume them.

2. The author says that at some point the queue may be full, and awaiting put call will block the producer. That’s true, but I believe this is fine. I might be mistaken, but isn’t this an example of backpressure? If your consumer(s) cannot process the flood of events in a timely fashion, then you want to stop producing. Otherwise, you may end up creating thousands of tasks, all awaiting the queue, and at some point, your producer will run out of memory.

This is just my two cents, I would be happy to hear other opinions (maybe @econchick will jump in?). I'll keep on reading anyway, and maybe add some notes later.

This is an excellent publication!

I came across this after finding out that I cannot propagate an error that takes place within a task that is created by the main loop inside another context.

Do you plan to update the guide with the latest python API? (3.10?)