Inside a running asyncio loop, how can a sync function get a coroutine's result?

## Why re-entry is impossible An event loop is a `while` loop over ready callbacks running on one thread. Being inside a coroutine means that loop's frame is already on this thread's stack, part-way through a callback. Starting another iteration of the same loop from inside that callback would re-enter the scheduler with half-finished state; asyncio refuses instead. The refusals differ by entry point but not in meaning: * `asyncio.run(coro)` checks for a running loop first and raises `RuntimeError: asyncio.run() cannot be called from a running event loop`. * `loop.run_until_complete(coro)` on the loop you are already inside raises `RuntimeError: This event loop is already running`. Creating a *fresh* loop in the same thread and running it does not help either: it sets a second loop as current, and any object created under the outer loop - a task, a future, a lock, a connection pool - is bound to the wrong loop and will misbehave or raise about attachment to a different loop. ## Where the situation comes from Almost always from a boundary that was never converted. A synchronous helper - a cache lookup, an audit hook, an ORM-style lazy attribute, a serializer callback - is called deep inside async code, and it needs something only an async client can give it. The temptation is to "just run" the coroutine right there. That is *sync over async*, and it is the everyday production hang: either the immediate `RuntimeError`, or, if someone gets past it, a thread deadlocked waiting on a loop it is itself blocking. ## Fix 1: make the caller async The function that needs an `await` becomes `async def`, its callers become `async def`, and the change stops at the outermost entry point that already runs the loop. This is the fix that removes the problem rather than moving it. The objection is always that the colour change ripples; that ripple is information, showing exactly how much of the codebase sits on the I/O path. ## Fix 2: push the sync code onto a thread and bridge back When the helper genuinely cannot change - a callback signature you do not own, a third-party extension point - do not run the loop from the loop thread. Move the helper off it: ```python loop = asyncio.get_running_loop() result = await asyncio.to_thread(helper, loop, arg) ``` and inside `helper`, which is now on a worker thread, block on the loop legitimately: ```python value = asyncio.run_coroutine_threadsafe(fetch(arg), loop).result(10) ``` This works because the blocking wait happens on a thread that is *not* the loop thread, so the loop stays free to run `fetch`. Its costs are real: one pool worker is parked for the whole call, so a burst of such calls can exhaust the default executor - and if the loop thread is ever blocked, every bridged worker blocks with it. Always pass a timeout to `.result()`, and remember cancellation does not cross the bridge in either direction. ## Fix 3: give the sync world its own loop For a mostly-synchronous program that needs async pieces, start a loop with `run_forever()` on a dedicated daemon thread and submit everything to it with `run_coroutine_threadsafe`. The blocking code never sees a loop on its own thread, so re-entry never arises. That is the shape the standard bridge helpers implement; libraries like `anyio` package it as a portal, and the ASGI-side `asgiref` package exposes it as `async_to_sync`/`sync_to_async` pairs with thread-affinity control. Under all of them are the same two primitives, and their caveats travel too. ## What not to do Monkey-patching the loop so it can be re-entered - the popular nested-loop shim - makes the exception disappear without making re-entry safe. Ordering guarantees break, tasks resume inside other tasks, and libraries that assume one activation per loop misbehave in ways that surface as impossible interleavings much later. It is acceptable in a notebook, never in a service. Equally wrong is `time.sleep()` or a blocking `.result()` on the loop thread "just until the future is done". The loop is the thing that would complete that future; blocking it guarantees the wait never ends. ## The diagnostic habit When you see the `RuntimeError`, read the traceback for the *synchronous* frame between two async frames. That frame is the boundary, and the decision is only ever: move the boundary up (make it async), or move the frame off the loop thread (bridge it). Anything else is a workaround with a hang attached.