3

I've never used the async-await syntax but I do often need to make HTTP/S requests and parse responses while awaiting future responses. To accomplish this task, I currently use the ThreadPoolExecutor class which execute the calls asynchronously anyways; effectively I'm achieving (I believe) the same result I would get with more lines of code to use async-await.

Operating under the assumption that my current implementations work asynchronously, I am wondering how the async-await implementation would differ from that of my original one which used Threads and a Queue to manage workers; it also used a Semaphore to limit workers.

That implementation was devised under the following conditions:

  • There may be any number of requests
  • Total number of active requests may be 4
  • Only send next request when a response is received

The basic flow of the implementation was as follows:

  1. Generate container of requests
  2. Create a ListeningQueue
  3. For each request create a Thread and pass the URL, ListeningQueue and Semaphore
  4. Each Thread attempts to acquire the Semaphore (limited to 4 Threads)
  5. Main Thread continues in a while checking ListeningQueue
  6. When a Thread receives a response, place in ListeningQueue and release Semaphore
  7. A waiting Thread acquires Semaphore (process repeats)
  8. Main Thread processes responses until count equals number of requests

Because I need to limit the number of active Threads I use a Semaphore, and if I were to try this using async-await I would have to devise some logic in the Main Thread or in the async def that prevents a request from being sent if the limit has been reached. Apart from that constraint, I don't see where using async-await would be any more useful. Is it that it lowers overhead and race condition chances by eliminating Threads? Is that the main benefit? If so, even though using a ThreadPoolExecutor is making asynchronous calls it is using a pool of Threads, thus making async-await a better option?

1 Answers1

4

Operating under the assumption that my current implementations work asynchronously, I am wondering how the async-await implementation would differ from that of my original one which used Threads and a Queue to manage workers

It would not be hard to implement very similar logic using asyncio and async-await, which has its own version of semaphore that is used in much the same way. See answers to this question for examples of limiting the number of parallel requests with a fixed number of tasks or by using a semaphore.

As for advantages of asyncio over equivalent code using threads, there are several:

  • Everything runs in a single thread regardless of the number of active connections. Your program can scale to a large number of concurrent tasks without swamping the OS with an unreasonable number of threads or the downloads having to wait for a free slot in the thread pool before they even start.

  • As you pointed out, single-threaded execution is less susceptible to race conditions because the points where a task switch can occur are clearly marked with await, and everything in-between is effectively atomic. The advantage of this is less obvious in small threaded programs where the executor just hands tasks to threads in a fire-and-collect fashion, but as the logic grows more complex and the threads begin to share more state (e.g. due to caching or some synchronization logic), this becomes more pronounced.

  • async/await allows you to easily create additional independent tasks for things like monitoring, logging and cleanup. When using threads, those do not fit the executor model and require additional threads, always with a design smell that suggests threads are being abused. With asyncio, each task can be as if it were running in its own thread, and use await to wait for something to happen (and yield control to others) - e.g. a timer-based monitoring task would consist of a loop that awaits asyncio.sleep(), but the logic could be arbitrarily complex. Despite the code looking sequential, each task is lightweight and carries no more weight to the OS than that of a small allocated object.

  • async/await supports reliable cancellation, which threads never did and likely never will. This is often overlooked, but in asyncio it is perfectly possible to cancel a running task, which causes it to wake up from await with an exception that terminates it. Cancellation makes it straightforward to implement timeouts, task groups, and other patterns that are impossible or a huge chore when using threads.

On the flip side, the disadvantage of async/await is that all your code must be async. Among other things, it means that you cannot use libraries like requests, you have to switch to asyncio-aware alternatives like aiohttp.

user4815162342
  • 141,790
  • 18
  • 296
  • 355
  • Since ThreadPoolExectuor runs async calls, is the difference the same in that async operations are occurring with Threads instead of a single one? –  Feb 24 '19 at 01:39
  • I suppose a better way to ask is why use `async-await` over supplying a method to a ThreadPoolExecutor and process futures as they complete? Why define a method as `async def` and then run an Executor in a separate thread within? –  Feb 24 '19 at 05:31
  • @datta This answer refers to using a native async/await library such as [asyncio](https://docs.python.org/3/library/asyncio.html). In that case IO-bound tasks don't require threads *at all*. Mixing `async def` with threaded code doesn't make much sense, except when invoking legacy blocking code, which should be done using [`run_in_executor`](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.run_in_executor). – user4815162342 Feb 24 '19 at 07:25
  • Right, but I was asking why would I write an `async def` script and injected an executor for blocking code, when I could do something like [this](https://docs.python.org/3/library/concurrent.futures.html#threadpoolexecutor-example). If I am querying websites, using `async-await`, I still have to use an executor to call `requests.get` for example, thus spawning threads. So whats the tradeoff? Why write a bunch of `async def` to ultimate use an executor for blocking calls, when I could've used an executor from the start. Whats the major difference? –  Feb 24 '19 at 14:23
  • A perfect example of your injection is [here](https://stackoverflow.com/a/33399896/8371266). They tell the event loop to await (ultimately suspend) the call that is blocking in the executor. Well had the whole script been written to query websites using an executor, the main thread would be sitting in a loop using `as_completed` to process futures as the complete since ThreadPoolExecutors are async and main is free to do other stuff. I don't even have to implement a check to see if all futures are done. So again, why use `async def/async-await` over a full ThreadPoolExecutor? –  Feb 24 '19 at 14:27
  • @datta It doesn't make sense to use async/await and still have threads under the hood. The idea with async/await is **not** to use threads, but actual asynchronous IO, and **then** you get the benefits outlined in my answer. Otherwise, there is very little point to the exercise. – user4815162342 Feb 24 '19 at 18:29
  • I agree. To have a thread call inside async code seems pointless. So I'm trying to understand, if I have a call that blocks like `requests.get`, and I had no other alternative (like `aiohttp`), when would I won't to choose async/await over just a pure ThreadPoolExecutor? Seems like if I use async/await I have to use it anyways. –  Feb 25 '19 at 14:36
  • @datta I think answer to that depends on the complexity of the program. If it's a smallish program, I'd just use futures and executors. If it's a more complex program, I'd consider using asyncio anyway, so that I can later introduce _other_ stuff that requires asyncio (websockets, aioredis, etc.) without issues. – user4815162342 Feb 25 '19 at 14:39
  • For a simple website query and download response to file, seems like futures and executors are fine. But that leads to the question: how are futures/executors async? Do they just appear async since they run concurrently? Clearly they aren't single threaded like a true async program. –  Feb 25 '19 at 15:16