3 ms·
In production systems, you don't use coroutines alone. You have several processes, some may contain several threads, some thread may contain an event loop. In
by BiteCode_dev 6y ago
In production systems, you don't use coroutines alone. You have several processes, some may contain several threads, some thread may contain an event loop.
In fact, it's already the case with WSGI setups: you may have async nginx on front, multi-process gunicorn behind, and a thread pool for you db connections. And asyncio already provides API for sending tasks to process pools and threads and getting them back as async Future as a convenience. It's turtles all the way down.
Bottom line, async, threads or processes are not silver bullets, and you should use the right tool for the right job.
Just like when Go users realized that spawning goroutines for everything actually didn't work at scale, throwing awaits everywhere is not a magical solution.
Having asyncio at your disposal make some tasks easier, like websockets, crawling your network, etc. It opened the door for new architectures, and maybe new features (live settings, task queues that feeds the results back to you, etc.).
But it's been oversold, as with anything new and shiny.
- 3pt14159 6y agoAsync is perfect for things like bulk uploading to DynamoDb while you munge through input files or save metadata to postgres. But for 97% of the use cases it's easier to use multiple processes and a normal worker queue.