Hacker News Reader

Comment by omh1280 | Hacker News Reader

Great read!

Python asyncio can really screw up your runtime performance if you use it poorly. And it's _really_ easy to use poorly.

Consider a FastAPI server using asyncio instead of threading. _Any_ time you drop down into a synchrononous API, you better be sure that you're not doing anything slow. For example, encoding or decoding JSON in Python actually grabs the GIL depending on what library you're using, and then you have no hope of releasing control back to asyncio.

View on HN

That's a GIL problem not an async problem. Even if you choose to ditch asyncio and use threads, you still need to care about the GIL. And when I use asyncio I don't worry about CPU-bound tasks like encoding or decoding JSON; I worry about some library doing I/O synchronously regardless of whether such library releases the GIL or not.

This is spot on. GIL-less python will be a thing, and when it happens, there will still be no reason to combine asyncIO with thread primitives. Waiting for IO can be spun off into a new thread, and it will work as you expect it would.

Trying to combine mental models of asyncio and threading is a model for pure insanity.

I fail to see why. You can have an event loop per thread, and a hypothetical requirement of wanting to make sure all compute in each thread is spent inside of its event loop (assuming OS level parallelism). Eg a latency-sensitive server in thread A and a logger in thread B (dont even need the event loop there for this example)

JSON encoding is, as someone else points out, a GIL problem, but I want to add that even if you do JSON encoding in an async context:

  async def foo(…):
    json.dumps(d)  # you're blocking the event loop

You're still going to block on it.

  def sync_foo(…):
    json.dumps(d)  # you're holding the GIL … and so blocking here too

Short of resolving the GIL somehow (either by getting ridding of it, which I think is still a WIP though it has been "merged", I believe) or subinterpreters, etc., JSON is inherently going to need to hold the GIL while it walks the structure it is encoding. (Unlike a large file I/O, where it might be possible to release the GIL during the I/O if we have a strong ref to an immutable buffer.)

This is more of a usability problem. In the second example, it's obvious that `json.dumps()` blocks everything else and it can be readily observed. It's not obvious that it blocks in the former and I've encountered many surprised coworkers despite it seeming obvious to me.

I think a lot of people assume you can slap `async` onto the function signature and it will not block anything anymore. I've had PRs come through that literally added `async` to a completely synchronous function with that misunderstanding.

Reply on news.ycombinator.com