rather than "What Python's asyncio primitives get wrong" this seems more like "why we chose one asyncio primitive (queue) instead of others (event and condition)"
also, halfway through the post, the problem grows a new requirement:
> Instead of waking consumers and asking "is the current state what you want?", buffer every transition into a per-consumer queue. Each consumer drains its own queue and checks each transition individually. The consumer never misses a state.
if buffering every state change is a requirement, then...yeah, you're gonna need a buffer of some kind. the previous proposed solutions (polling, event, condition) would never have worked.
given the full requirements up-front, you can jump straight to "just use a queue" - with the downside that it would make for a less interesting blog post.
also, this is using queues without any size limit, which seems like a memory leak waiting to happen if events ever get enqueued more quickly than they can be consumed. notably, this could not happen with the simpler use cases that could be satisfied by events and conditions.
> A threading.Lock protects the value and queue list.
unless I'm missing something obvious, this seems like it should be an asyncio.Lock?
yes. I felt something very similar. I do think there is value in pointing out the pitfalls naieve users (me!) can make assuming things which aren't true about ordering of events, states. Queues with lock regions are also really nice because they are (as I understand it) very cheap: so making a thread or other concurrency primitive which writes into a queue under lock, and gets out of the way, aligns nicely with having some mothership process which reads queues under lock in a deterministic way. Actual event order can vary. but you should be able to know you had an event putting you into state A, as well as the terminal event state B you jumped into without doing work needed for state A.
One thing that trips people up with asyncio is that “single threaded” gets interpreted as “no concurrency hazards”.
But coroutines still interleave execution at every await point, so shared mutable state can become just as fragile as in multithreaded code — the scheduling boundary just moves from OS threads to cooperative yield points.
In practice that tends to push designs toward queues, actors, or message-passing patterns if you want to avoid subtle state corruption.
I don't fully agree with this. Yes, surely shared mutable state can suffer from similar issues, however the cooperative nature of coroutines makes this much easier to handle. OS threads are preemptive and actually run in parallel, so you have to be aware of CPU concurrency and always be ready for a context switch.
And in that case you begin to wonder why use Python at all? The language struggles to give developers the granularity needed to finely manage threads like C++, and it doesn't have the actor model first class like Erlang. I love Python, but I love Fortran and Lisp too. They've all served their purpose and it's time to move on, even though there is already incredible momentum behind it.
I think it’s not so much that the asyncio primitives got wrong about shared state, as much as is what the authors got wrong about the usage of those primitives. They are classic concurrency primitives that’s been around for almost half a century. They work as designed, but require some care to use correctly.
What about a more general message-passing mailbox approach? This works really well in the Erlang/gen_server/gen_fsm world. (and in plenty of other contexts, but Erlang's OTP is still some of the best, simplest incarnation of these things)
I'm sorry but how do you jump from 1. Polling to 2. Asyncio
There's so many solutions in the middle, I have this theory that most people that get into async don't really know what threading is. Maybe they have a world vision where before 2023 python just could not do more than one thing at once, that's what the GIL was right? But now after 3.12 Guido really pulled himself by the bootstraps and removed the GIL and implemented async and now python can do more than one thing at a time so they start learning about async to be able to do more than one thing at a time.
This is a huge disconnect between what python devs are actually building, a different api towards concurrency. And some junior devs that think they are learning bleeding edge stuff when they are actually learning fundamentals through a very contrived lens.
It 100% comes from ex-node devs, I will save the node criticism, but node has a very specific concurrency model, and node devs that try out python sometimes run to asyncio as a way to soften the learning curve of the new language. And that's how they get into this mess.
The python devs are working on these features because they have to work on something, and updates to foundational tech are supposed to have effects in decades, it's very rare that you need to use bleeding edge features. In 95% of the cases, you should be restricting yourself to using features from versions that are 5-10 years old, especially if you come from other languages! You should start old to new, not new to old.
Sorry, for the rant, or if I misjudged, making a broader claim based on multiple perspectives.
the title seems unnecessarily clickbaity.
rather than "What Python's asyncio primitives get wrong" this seems more like "why we chose one asyncio primitive (queue) instead of others (event and condition)"
also, halfway through the post, the problem grows a new requirement:
> Instead of waking consumers and asking "is the current state what you want?", buffer every transition into a per-consumer queue. Each consumer drains its own queue and checks each transition individually. The consumer never misses a state.
if buffering every state change is a requirement, then...yeah, you're gonna need a buffer of some kind. the previous proposed solutions (polling, event, condition) would never have worked.
given the full requirements up-front, you can jump straight to "just use a queue" - with the downside that it would make for a less interesting blog post.
also, this is using queues without any size limit, which seems like a memory leak waiting to happen if events ever get enqueued more quickly than they can be consumed. notably, this could not happen with the simpler use cases that could be satisfied by events and conditions.
> A threading.Lock protects the value and queue list.
unless I'm missing something obvious, this seems like it should be an asyncio.Lock?
yes. I felt something very similar. I do think there is value in pointing out the pitfalls naieve users (me!) can make assuming things which aren't true about ordering of events, states. Queues with lock regions are also really nice because they are (as I understand it) very cheap: so making a thread or other concurrency primitive which writes into a queue under lock, and gets out of the way, aligns nicely with having some mothership process which reads queues under lock in a deterministic way. Actual event order can vary. but you should be able to know you had an event putting you into state A, as well as the terminal event state B you jumped into without doing work needed for state A.
One thing that trips people up with asyncio is that “single threaded” gets interpreted as “no concurrency hazards”.
But coroutines still interleave execution at every await point, so shared mutable state can become just as fragile as in multithreaded code — the scheduling boundary just moves from OS threads to cooperative yield points.
In practice that tends to push designs toward queues, actors, or message-passing patterns if you want to avoid subtle state corruption.
I don't fully agree with this. Yes, surely shared mutable state can suffer from similar issues, however the cooperative nature of coroutines makes this much easier to handle. OS threads are preemptive and actually run in parallel, so you have to be aware of CPU concurrency and always be ready for a context switch.
And in that case you begin to wonder why use Python at all? The language struggles to give developers the granularity needed to finely manage threads like C++, and it doesn't have the actor model first class like Erlang. I love Python, but I love Fortran and Lisp too. They've all served their purpose and it's time to move on, even though there is already incredible momentum behind it.
I think it’s not so much that the asyncio primitives got wrong about shared state, as much as is what the authors got wrong about the usage of those primitives. They are classic concurrency primitives that’s been around for almost half a century. They work as designed, but require some care to use correctly.
Agreed. This isn't an asyncio problem, it's just not how those primatices work.
Reminds me of https://geocar.sdf1.org/fast-servers.html
What about a more general message-passing mailbox approach? This works really well in the Erlang/gen_server/gen_fsm world. (and in plenty of other contexts, but Erlang's OTP is still some of the best, simplest incarnation of these things)
I'm sorry but how do you jump from 1. Polling to 2. Asyncio
There's so many solutions in the middle, I have this theory that most people that get into async don't really know what threading is. Maybe they have a world vision where before 2023 python just could not do more than one thing at once, that's what the GIL was right? But now after 3.12 Guido really pulled himself by the bootstraps and removed the GIL and implemented async and now python can do more than one thing at a time so they start learning about async to be able to do more than one thing at a time.
This is a huge disconnect between what python devs are actually building, a different api towards concurrency. And some junior devs that think they are learning bleeding edge stuff when they are actually learning fundamentals through a very contrived lens.
It 100% comes from ex-node devs, I will save the node criticism, but node has a very specific concurrency model, and node devs that try out python sometimes run to asyncio as a way to soften the learning curve of the new language. And that's how they get into this mess.
The python devs are working on these features because they have to work on something, and updates to foundational tech are supposed to have effects in decades, it's very rare that you need to use bleeding edge features. In 95% of the cases, you should be restricting yourself to using features from versions that are 5-10 years old, especially if you come from other languages! You should start old to new, not new to old.
Sorry, for the rant, or if I misjudged, making a broader claim based on multiple perspectives.
I think they were already in the async world and needed message passing -- the polling code was also in python async.