It gives good pointers but it falls short on the usual suspects for an article on asyncio.<p>When teaching it, it's important to emphasis:<p>- await is locally blocking, so you should isolate linear workflows into their own coro, which is the unit of concurrency.<p>- to allow concurrency, you should use asyncio.create_task on coro (formerly ensure_future).<p>- you should always explicitly delimitate the life cycle of any task. Right now, this means using something like gather() or wait(). TaskGroup will help when it becomes mainstream.<p>A HN comment is not great to explain that, but if you read the article, you should investigate those points. There is no good asyncio code without them, only pain and disapointment.
This is the bit that should be at the very top of the official docs. It's tripped me up every time I go to write async code and until you learn it, the error message is very confusing.<p>> In particular, calling it will immediately return a coroutine object, which basically says "I can run the coroutine with the arguments you called with and return a result when you await me".<p>> The code in the target function isn't called yet - this is merely a promise that the code will run and you'll get a result back, but you need to give it to the event loop to do that.<p>If I try to pass the async function to gather (for example) without calling it, which makes some intuitive sense, since functions are first class objects and I know I'm not calling it, the event loop is, the error message reads something like, "gather only accepts coroutines." But I thought it was a coroutine because I declared it with async! For some reason it took me a silly amount of time to notice that in all the examples, the async function is called when it's passed to gather (or whatever). That's not intuitive to me and the distinction made in the article should be clearer in the docs.
Similar question to the other one at the time of writing, but more specific: does anyone have a good, <i>thorough</i> introduction to the "async event loop" (sometimes known as "asyncio") pattern? By thorough I mean that it goes beyond a starter tutorial, into both examples of various supporting libraries and implementation details that matter for usage. I'm fine with a book, too.<p>There are popular libraries for it in both Python and Perl and I suspect I could make good use for it if I understood it.<p>Unfortunately, I've only ever used it in a cargo cult manner of sticking together functions until the error messages go away (yeah yeah, it was only for "throwaway" "prototypes") so I really don't understand how it all is meant to fit together.
I thought Python couldn't multithread because of GIL? I understood from the article that async derives all its benefit from certain OS-level operations which don't need to run in a coroutine, like reading from a network socket or waiting for timers to finish.<p>Another question: Is Python's implementation of async/await identical to other languages? In particular, do they always use coroutines instead of threads?
Can anyone recommend a good book/primer on "concurrency models" (is that a term?) for a self-taught programmer?<p>While I am self-taught, I'm used to (academic) books that strive for completeness. It is also what I prefer. Rather than something more pragmatic like a blog post.<p>It doesn't mean I want to read overly complicated prose on the subject, which I'm sure is possible.
Async is overengineered and bolted on. If you must use Python, I'd still recommend Twisted, which is more accessible. Otherwise, of course use Go, Elixir, etc. in the first place.
I am really interested in this space.<p>There's an article that Cal Paterson wrote that async doesn't speed up code - it is not parallel. The GIL prevents Python from being parallel. So even if you create a thread to run an async method in Python, it shall not run in parallel to the main thread of execution. (In fact, it shall block the main thread of execution if you start a thread in the thread you are in, due to the blocking run_in_executor)<p><a href="https://calpaterson.com/async-python-is-not-faster.html" rel="nofollow">https://calpaterson.com/async-python-is-not-faster.html</a><p>I wrote a multithreaded userspace 1:M:N scheduler (1 scheduler thread, M kernel threads and N lightweight/green threads) which resembles Golang M:N model. I implemented the same design in Rust, C and Java. I am thinking it could be combined with my epoll-server and it would be an application server.<p><a href="https://github.com/samsquire/preemptible-thread" rel="nofollow">https://github.com/samsquire/preemptible-thread</a>
<a href="https://github.com/samsquire/epoll-server" rel="nofollow">https://github.com/samsquire/epoll-server</a><p>I am also interested in structured concurrency. This article by Vala developers is good.<p><a href="https://verdagon.dev/blog/seamless-fearless-structured-concurrency" rel="nofollow">https://verdagon.dev/blog/seamless-fearless-structured-concu...</a><p>I am trying to find a concurrent software design that is scalable and is easy to write and hides complicated lock programming. I document my studies and ideas in the open in ideas4.<p><a href="https://github.com/samsquire/ideas4" rel="nofollow">https://github.com/samsquire/ideas4</a><p>I've implemented multithreaded parallel multiversion concurrency control in Java, which is the same approach used by Postgresql and MySQL for concurrent read and writing to the same data atomically.<p>I still think concurrency is hard to write and understand. Even with async/await.<p>// 3 requests in flight<p>result1 = async_task1();<p>result2 = async_task2();<p>result3 = async_task3();<p>await result1;<p>await result2;<p>await result3;<p>I ported a parallel multiconsumer multiproducer ringbuffer from Alek<p><a href="https://www.linuxjournal.com/content/lock-free-multi-producer-multi-consumer-queue-ring-buffer" rel="nofollow">https://www.linuxjournal.com/content/lock-free-multi-produce...</a><p>I use Python threads in <a href="https://github.com/samsquire/devops-schedule" rel="nofollow">https://github.com/samsquire/devops-schedule</a> and <a href="https://github.com/samsquire/parallel-workers" rel="nofollow">https://github.com/samsquire/parallel-workers</a> to parallelise a topologically sorted graph of IO of devops programs. This allows efficient scheduling and blocking with thread.join() for each split of the work graph and then a regrouping before doing other things, also potentially in parallel. This pattern is efficient and easy to use.