FastAPI: difference between run_in_executor and run_in_threadpool

David Y.
jump to solution

The Problem

In FastAPI, what’s the difference between run_in_executor and run_in_threadpool? As far as I can tell, both are used to execute a task in another thread. When should I use one over the other?

The Solution

Both run_in_executor and run_in_threadpool are used to run synchronous code (also called blocking code) in an asynchronous application without blocking the event loop. run_in_executor is a relatively low-level operation, originating in Python’s asyncio library, whereas run_in_threadpool comes from Starlette, the ASGI framework underlying FastAPI.

As a result, run_in_threadpool is simpler to use at the cost of flexibility, and run_in_executor is more flexible at the cost of increased complexity. Consider the following two code examples:

# Using run_in_executor
import asyncio
from concurrent.futures import ThreadPoolExecutor

def sync_function(argument1, argument2):
    # logic for the sync function here
    pass

async def main():
    loop = asyncio.get_running_loop()
    with ThreadPoolExecutor() as pool:
        result = await loop.run_in_executor(pool, sync_function, 'argument1', 'argument2')
# Using run_in_threadpool
from fastapi import FastAPI
from starlette.concurrency import run_in_threadpool

app = FastAPI()

def sync_function(argument1, argument2):
    # logic for the sync function here
    pass

async def example_route():
    result = await run_in_threadpool(sync_function, 'argument1', 'argument2')

As we can see, the run_in_threadpool code is simpler – unlike the run_in_executor code, it does not require us to specify an executor, as it will always use the default executor. Most of the time, this is what we want – run_in_threadpool is integrated with FastAPI’s design and is the recommended approach for most use cases.

However, if we have a complicated application that needs to integrate a variety of disparate synchronous systems, we may want the additional control that run_in_executor provides. For example, some applications may benefit from using ProcessPoolExecutor instead of ThreadPoolExecutor.

Considered "not bad" by 4 million developers and more than 150,000 organizations worldwide, Sentry provides code-level observability to many of the world's best-known companies like Disney, Peloton, Cloudflare, Eventbrite, Slack, Supercell, and Rockstar Games. Each month we process billions of exceptions from the most popular products on the internet.

Sentry