How do you schedule a callback onto a running asyncio event loop from another thread?

**The loop belongs to one thread, and there is a doorway.** An asyncio event loop keeps mutable state — a ready-callback queue, a timer heap, a selector registration table — with no locking around most of it, on the assumption that only its own thread touches it. That assumption is the design, not an oversight: single-threaded ownership is what lets asyncio skip locks on every internal structure. The consequence is a blunt rule: **call loop methods only from the loop's thread**, with two documented exceptions. **Scheduling on the loop's own thread.** `asyncio.AbstractEventLoop.call_soon(callback, *args)` appends a callback to the ready queue; it runs on the next iteration, in FIFO order relative to other `call_soon` callbacks, never immediately. `call_later(delay, callback, *args)` and `call_at(when, callback, *args)` put it on the timer heap; `when` is measured on the loop's own monotonic clock, which you read with the loop's `time()` — deliberately not wall-clock time, so a system clock adjustment cannot make a timer fire early, late, or twice. `call_soon` returns a `Handle` and the timer variants return a `TimerHandle`; both offer `cancel()`, and `TimerHandle` also reports `when()`. Keep the handle if you might need to cancel, exactly as you would keep a task reference. ```python import asyncio async def main(): loop = asyncio.get_running_loop() loop.call_soon(print, "next iteration") doomed = loop.call_later(0.05, print, "never runs") doomed.cancel() await asyncio.sleep(0.1) asyncio.run(main()) ``` Note what these are *for*: plain, fast, synchronous callbacks. They are the low-level scheduling primitive beneath tasks, not a replacement for them. If the thing you want to run is a coroutine, you want a task, not `call_soon`. And if you are inside async code and want to wait a while, `await asyncio.sleep(delay)` is clearer than `call_later` — you reach for `call_later` when the work is a callback with no one to await it, such as a periodic tick or a delayed cleanup fired from a callback context. **Crossing the thread boundary.** From a thread that is not the loop's, the two legal calls are `call_soon_threadsafe(callback, *args)`, which returns a `Handle`, and `asyncio.run_coroutine_threadsafe(coro, loop)`, which schedules a coroutine as a task on that loop and hands back a `concurrent.futures.Future` — an ordinary blocking future the calling thread may `result(timeout=...)` on. Everything else on the loop object is off limits from outside. Why a special method at all? Two reasons, and interviewers ask for both. First, the queue append must be serialized, so the threadsafe variant takes the lock the plain one does not. Second, and less obvious, the loop is usually *asleep*. Between iterations it sits inside a selector poll whose timeout is the next timer deadline, which might be seconds away; simply appending to the ready queue would leave your callback waiting for that timeout to expire. So the threadsafe call also writes a byte to the loop's internal self-pipe, a file descriptor the loop always has registered with its selector. That write makes the poll return at once, the loop runs an iteration, and the callback fires promptly. This is also why calling the loop's `stop()` from another thread does not work reliably — the loop may not notice until something wakes it. **Mistakes worth naming.** Passing an `async def` function to `call_soon` type-checks fine and does nothing useful: the callback is called, it returns a coroutine object, the object is discarded, and you get `RuntimeWarning: coroutine ... was never awaited` with the body never executed. Blocking inside a scheduled callback stalls the loop exactly as a blocking call inside a coroutine does, because it runs on the same thread. Assuming `call_later(0.05, ...)` means "in exactly 50 ms" is wrong in the same way any timer is: 50 ms is a floor, and a busy or blocked loop delivers it late. And using the loop object captured from another thread — storing it in a global and calling `create_task` on it from a worker — is a data race even when it appears to work; the threadsafe entry points exist precisely so you never have to. **One loop per thread** is the frame that ties this together. A thread that wants asyncio runs its own loop; threads talk to each other's loops only through these doorways.