[mivade]

My understanding was that if you write a regular function (`def` rather than `async def`) then FastAPI (or really Starlette which it uses under the hood) executes the function in a thread pool so that no blocking of the main event loop should occur.

[lukin0110]

I didn't explain it well in my comment. Consider the following example:

def blocking(): time.sleep(5)

@app.get("/") async def index(): blocking()

The `blocking` function will blocking the event loop. This is something you need to be aware of. Gist with a few scenarios: https://gist.github.com/lukin0110/0074ec5325224674010193bb95...

[kylebarron]

Isn't the point that you should be using `def`, not `async def` here?

[lukin0110]

Yes. But this is a very basic example. When you have an async function defined with `await` statements in it and later on in the function you do a call to a `blocking` function you need to be aware that you have to run in the threadpool.

You don't always know that a function call is blocking, because you don't always know what is happening behind the scenes of that function and on what it depends.

[mvolfik]

what is the benefit of threadpool though? am I understanding it correctly that due to GIL, python will just keep switching the threads, so instead of running A then B both at 100% speed, both will run concurrently at 50% speed (+/- overhead)?

[vgel]

Only if you're CPU bound, but usually your webserver is blocking on disk IO or database calls or whatever, not calculating stuff, in which case the GIL doesn't matter.

[playing_colours]

You can get benefits with IO bound work.