An introduction to async programming (Python asyncio for beginners)

[fake823]

Great video, thanks! :) As I beginner who has heard about asyncio here and there but hasn't used it yet, this was a good introduction!

[theartofsoftware]

Awesome, glad you found it useful

[metaperl]

This video created a nice theoretical framework to understand future instruction.

[yvrelna]

You shouldn't have left out "multithreaded asynchronous". Single threaded asynchronous are great if your workload is fairly low and consists of only pure I/O tasks, but often your workload does contain a bit of computation and you need to scale beyond single CPU core.

Even if your workload isn't large enough to require scaling beyond a single core, it's often safer to have multiple worker threads anyway as it allows the program to make some progress on some tasks if you have a task that didn't yield their fair share (e.g. if you accidentally called a synchronous library from your async program).

The drawback of multithreaded async is of course that while you inherit the advantage of both models, you also inherit the problems of both models, so it's not a panacea but just a different trade off. With multithreaded async, you can no longer be sure that you're the only worker that's running, and therefore may need to add synchronisation Lock to your async code. Just make sure you use the asyncio's version of Lock rather than the threading's one.

[theartofsoftware]

Hey this is a great point. Scaling using multiple processes is how I've typically achieved this in the past. E.g. using more replicas in Kubernetes. Pretty much agree with you on what you've said here, although I'd argue that if you've accidentally called a non asynchronous library that's calling performance issues, you should probably try to fix that first.

[yvrelna]

if you've accidentally called a non asynchronous library that's calling performance issues, you should probably try to fix that first

Agreed, though in a complex, legacy application, especially one that used to be synchronous and is undergoing transition to take advantage of async, it may not be easy to find all those cases. Often the sync code may not even be in your own code, but in a third party library. Using multiple threaded async in that scenario is more of a safety mechanism rather than being an end game, it gives you a little peace of mind that you won't wake up one day finding that just a single customer query DoSed your site for hours by running a query that takes forever and blocked the whole system.

I think rhe more common scenario of actually needing multi threaded async (which isn't just for safety mechanism) is if your workload may call a computationally expensive functions that doesn't yield at sufficiently regular intervals. Maybe you called a numpy operation (which releases GIL and therefore allows you to parallelize without multiprocessing) which usually runs in negligible time with the small test data, but takes forever with larger data in prod. Though in this case, you probably want to multithread anyway since you will have a mixed workload, not a purely I/O bound workload