Bridging sync and async: to_thread and executors one way, a long-lived loop and run_coroutine_threadsafe the other

Async to sync: getting blocking work off the loop

Lesson 1 proved why the loop must never wait: one blocking call freezes the selector poll. The pressure valves are two, and choosing between them is GIL math from the concurrency unit. await asyncio.to_thread(fn, *args) (3.9+) runs fn in the loop’s default ThreadPoolExecutor and propagates contextvars; loop.run_in_executor(pool, fn) is the older, pool-explicit form. For blocking I/O — a sync DB driver, requests, file reads — a thread is the full answer: the thread parks in a syscall holding nothing, the loop runs free. For CPU-bound work, the GIL still serializes Python bytecode across threads: to_thread keeps the loop responsive-ish (the GIL changes hands every ~5 ms, so the loop progresses between slices) but buys zero throughput and degrades loop latency under contention. Real CPU parallelism means ProcessPoolExecutor — paying the pickling tax both ways and process startup, worth it from tens of milliseconds of CPU per item.

The sizing trap is the default executor: min(32, cpu_count + 4) threads. Forty concurrent to_thread(requests.get, ...) calls on an 8-core box means 12 threads working and 28 calls queued invisibly — your “async” endpoint now has a hidden thread-pool wait in its p99. The same shape you met in the web-services unit, where the framework offloads sync endpoints to a default 40-thread pool: every bridge has a width, and an unmeasured width is a latency cliff. Size an explicit executor to the dependency it protects (a 10-connection DB needs ~10 threads, not 32).

pool = concurrent.futures.ThreadPoolExecutor(max_workers=10, thread_name_prefix="db")

async def get_user(uid):
    loop = asyncio.get_running_loop()
    return await loop.run_in_executor(pool, db.fetch_user, uid)   # bounded bridge

Sync to async: three tools, three situations

The reverse direction has a tool per situation, and confusing them is the Hook incident. asyncio.run(coro) creates a fresh loop, runs to completion, closes the loop — correct exactly once per process lifetime-ish: scripts, main(), tests. Everything loop-bound — connection pools, sessions, transports — dies with the loop, which is why per-request asyncio.run rebuilt the SDK’s world two thousand times a minute. asyncio.run_coroutine_threadsafe(coro, loop) submits a coroutine into a running loop from another thread and returns a concurrent.futures.Future — the sync kind, whose .result(timeout) blocks the calling thread, not the loop. That is the server-grade bridge: one long-lived loop in a dedicated thread, every sync caller handing coroutines across:

class AsyncBridge:
    def __init__(self):
        self.loop = asyncio.new_event_loop()
        threading.Thread(target=self.loop.run_forever, daemon=True, name="bridge").start()

    def call(self, coro, timeout=None):
        fut = asyncio.run_coroutine_threadsafe(coro, self.loop)   # thread-safe handoff
        return fut.result(timeout)        # blocks THIS thread; the loop runs free

bridge = AsyncBridge()                    # one loop, one connection pool, per process
def view(request):                        # sync WSGI view, unchanged framework
    return bridge.call(client.search(request.GET["q"]), timeout=5)

The third situation is the error you will meet first: calling asyncio.run (or loop.run_until_complete) while a loop is already running raises RuntimeError: asyncio.run() cannot be called from a running event loop — the loop is not re-entrant by design; a nested run would have to pause the iteration mid-drain. Jupyter is the classic collision (the notebook itself runs a loop — that is why top-level await works there). nest_asyncio, honestly: it monkeypatches the loop to allow re-entrant run_until_complete, which works in a notebook and violates the loop’s invariants everywhere else — a diagnostic clue in prod (“someone is fighting the architecture”), not a fix.

Contagion management and the boundary rules

Async is contagious upward — every caller of a coroutine must itself await or bridge — and each bridge crossing costs a thread hop, future bookkeeping, and a wake of the target thread: tens of microseconds at best, plus pool-width queueing at worst. The architecture rule: one boundary. Keep a sync core with an async edge (the Django bridge above), or an async core with sync leaf-calls via to_thread — and refuse mid-stack sprinkling, where layer three is async, layer four sync, layer five async again, each transition a bridge with its own width, timeout, and failure mode.

At the boundary itself, thread safety is absolute: loop objects are not thread-safe, and the only legal entries from a foreign thread are loop.call_soon_threadsafe(cb) and run_coroutine_threadsafe. The mechanism closes lesson 1’s circle: the loop may be parked in selector.select(timeout) — asleep in the kernel. call_soon_threadsafe appends the callback and writes a byte to a self-pipe the selector watches, waking the loop immediately. Plain call_soon from a foreign thread skips the wake-up: the callback sits unnoticed until the next natural wakeup — or corrupts internal state outright. Never call task.cancel(), future.set_result(), or any loop method directly from another thread; wrap it in call_soon_threadsafe.