Mixing blocking code with asyncio

Practice that adapts to you

Practise this lesson

8 questions about 10 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.

1. Question 1 of 8 What does asyncio's debug mode log by default when a task step runs for 0.3 seconds?

   Choose one answer.

   A warning only if the step took longer than 1 second Nothing: debug mode only reports coroutines that were never awaited An exception raised inside the slow task A warning about that step and how long it took, because it is over the 100 ms limit

   Show the answer: Question 1 of 8

   Answer: A warning about that step and how long it took, because it is over the 100 ms limit

   With debug mode on, asyncio.run(main(), debug=True), the event loop logs every step that holds it for more than 100 milliseconds, which finds the blocking calls you missed.

2. Question 2 of 8 Which of these blocks the event loop when it runs inside a coroutine?

   Choose one answer.

   await asyncio.sleep(1) time.sleep(1) asyncio.create_task(job()) await asyncio.to_thread(time.sleep, 1)

   Show the answer: Question 2 of 8

   Answer: time.sleep(1)

   A call that waits or computes without awaiting, such as time.sleep(), freezes the event loop and every task on it until it returns.

3. Question 3 of 8 What does ticker_hash.py print?

   What does this program print? Choose one answer.

   import asyncio
   import hashlib
   import time
   
   DATA = bytes(range(256)) * (64 * 1024)            # 16 MiB, hashed 32 times: 512 MiB of work
   
   
   def checksum(data):
       """Blocking work, like hashing a big file: it keeps one thread busy for a while."""
       h = hashlib.sha256()
       for _ in range(32):
           h.update(data)
       return h.hexdigest()
   
   
   async def ticker(ticks, stop):
       while not stop.is_set():
           ticks.append(time.perf_counter())
           await asyncio.sleep(0.01)
   
   
   async def measure(run_checksum):
       ticks, stop = [], asyncio.Event()
       task = asyncio.create_task(ticker(ticks, stop))
       await asyncio.sleep(0.05)                     # the ticker is running
       start = time.perf_counter()
       digest = await run_checksum()
       took = time.perf_counter() - start
       stop.set()
       await task
       during = sum(start < t < start + took for t in ticks)
       return digest, took, during
   
   
   async def main():
       async def on_the_loop():
           return checksum(DATA)                     # called directly inside a coroutine
   
       async def in_a_thread():
           return await asyncio.to_thread(checksum, DATA)
   
       d1, took1, ticks1 = await measure(on_the_loop)
       d2, took2, ticks2 = await measure(in_a_thread)
       print(f"same digest both ways: {d1 == d2}")
       print(f"called directly:  {ticks1} ticks of a 10 ms ticker during the hash")
       print(f"with to_thread(): the ticker kept ticking during the hash: {ticks2 >= 0.5 * took2 / 0.01}")
   
   
   asyncio.run(main())

   same digest both ways: True called directly: 0 ticks of a 10 ms ticker during the hash with to_thread(): the ticker kept ticking during the hash: True same digest both ways: False called directly: 0 ticks of a 10 ms ticker during the hash with to_thread(): the ticker kept ticking during the hash: True same digest both ways: True called directly: 0 ticks of a 10 ms ticker during the hash with to_thread(): the ticker kept ticking during the hash: False

   Show the answer: Question 3 of 8

   Answer: it prints

   same digest both ways: True
   called directly:  0 ticks of a 10 ms ticker during the hash
   with to_thread(): the ticker kept ticking during the hash: True

   Both ways compute the same SHA-256 digest. Called directly, the hash holds the event loop's thread, so the ticker task cannot run once until it ends. With to_thread(), the hash runs in a worker thread, and because hashlib releases the GIL while hashing large buffers, the ticker keeps its 10 ms rhythm.

4. Question 4 of 8 Which bridge copies the caller's context variables into the thread that runs the call?

   Choose one answer.

   loop.run_in_executor() with your own thread pool None of them asyncio.to_thread() loop.run_in_executor() with a process pool

   Show the answer: Question 4 of 8

   Answer: asyncio.to_thread()

   to_thread() copies the context variables into the thread; run_in_executor() does not, and a process pool gets only what it pickles.

5. Question 5 of 8 An async web service must resize uploaded images with a pure-Python function that computes for about a second. Where should the call run?

   Choose one answer.

   Directly in the coroutine, since it does no I/O In asyncio.to_thread(resize, data), which runs it in parallel with the event loop In a process pool, through loop.run_in_executor(pool, resize, data) In a coroutine that calls await asyncio.sleep(0) before resizing

   Show the answer: Question 5 of 8

   Answer: In a process pool, through loop.run_in_executor(pool, resize, data)

   Called directly, the computation blocks the event loop for a second. A thread of the default build would hold the GIL while running Python code, so the loop would still be slowed. A process has its own interpreter and GIL, so the computation runs beside the loop; the function and its arguments must be picklable.

6. Question 6 of 8 What does asyncio.run(main()) do?

   Choose one answer.

   It creates a new event loop, runs main() to its end and closes the loop It reuses one loop for every call in the program It schedules main() on the loop that is already running It runs main() in a worker thread

   Show the answer: Question 6 of 8

   Answer: It creates a new event loop, runs main() to its end and closes the loop

   asyncio.run() creates an event loop, runs one coroutine and closes the loop; use it for a program's single entry point.

7. Question 7 of 8 A synchronous command-line tool calls two coroutines in turn, and both use one client object that holds an asyncio queue. Why is asyncio.Runner a better fit than calling asyncio.run() twice?

   Choose one answer.

   asyncio.run() cannot return a value, and a Runner can asyncio.run() may only be called from inside a coroutine A Runner runs the two coroutines at the same time A Runner runs both calls on one event loop, while each asyncio.run() creates a new loop and the queue is bound to the first

   Show the answer: Question 7 of 8

   Answer: A Runner runs both calls on one event loop, while each asyncio.run() creates a new loop and the queue is bound to the first

   asyncio.run() creates an event loop, runs one coroutine and closes the loop. Objects that waited on the first loop are bound to it, so the second call fails with "bound to a different event loop". A Runner keeps one loop and one context for all of its run() calls, and still runs them one after another.

8. Question 8 of 8 Synchronous test code calls three async functions that share one client with a connection pool inside. What do the tests use?

   Choose one answer.

   asyncio.run() for each call One asyncio.Runner for the three calls A new client per call, each with asyncio.run() asyncio.get_event_loop().run_until_complete() for each call

   Show the answer: Question 8 of 8

   Answer: One asyncio.Runner for the three calls

   Use asyncio.run() for a single entry point and a Runner when synchronous code makes several async calls that share objects, such as a client with a pool or a queue.