4 ms·

I'm confused, in the example application I see all these async endpoints interacting with the database, but the function bodies are entirely sync. Wouldn't this

I'm confused, in the example application I see all these async endpoints interacting with the database, but the function bodies are entirely sync. Wouldn't this block the event loop?

vednig 2y ago
Based on my experience. At some places where there were no better alternatives, framework utilizes sync functions under the hood, such as some databases. Overall there are also places where functions are async running in sync bodies, but they're not running on main thread.
- whilenot-dev 2y ago
  To GP: yes, it would block the event loop and that's pretty bad. But... asyncio.to_thread[0] as a quick workaround, just keep track of your thread count. Obviously frameworks and libraries with asyncio support should be chosen whenever possible. > Overall there are also places where functions are async running in sync bodies, but they're not running on main thread. That would be a design mistake, as functions have colors[1] with async/await. That's currently my biggest gripe in the python ecosystem, apart from modules maintaining their own hidden state. [0]: https://docs.python.org/3/library/asyncio-task.html#asyncio.to_thread https://docs.python.org/3/library/asyncio-task.html#asyncio.... [1]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
deleted 2y ago
[deleted]
Retr0id 2y ago
Presumably, they would - hopefully, the work they're doing is quick enough that it doesn't really matter that they're blocking (this is usually true when interacting with sqlite, for example). Async request handlers are nice to have for when you do want to do something genuinely async (like firing off another HTTP request to somewhere else)
odie5533 2y ago
It looks like the author is mistakenly using the sync versions of SQLAlchemy calls. Unless it's on purpose. Either way, not a good sign.
- wesselbindt 2y ago
  I can't imagine someone having the chops to code up their own web framework and making a mistake like this. There must be something that we're missing. Another commenter suggested that since it's SQLite, the blocking calls are quick enough not to care, which may be true. I don't know enough about SQLite's performance characteristics to judge that. In general I assume disk I/O is slow enough (even on SSD) to care about blocking the event loop and delegating the calls to a thread. But I've been wrong about this before. For example, a call to stat is technically blocking, but the overhead of delegating it to a thread is actually more expensive (on my Framework 13) and blocks the loop longer than just doing the call outright in the main thread.
  - anentropic 2y ago
    FWIW... CloudFlare Durable Objects rely on sync calls to SQLite being fast https://blog.cloudflare.com/sqlite-in-durable-objects/ https://blog.cloudflare.com/sqlite-in-durable-objects/

I'm confused, in the example application I see all these async endpoints interacting with the database, but the function bodies are entirely sync. Wouldn't this block the event loop?

vednig 2y ago

Based on my experience. At some places where there were no better alternatives, framework utilizes sync functions under the hood, such as some databases. Overall there are also places where functions are async running in sync bodies, but they're not running on main thread.

whilenot-dev 2y ago
To GP: yes, it would block the event loop and that's pretty bad. But... asyncio.to_thread[0] as a quick workaround, just keep track of your thread count. Obviously frameworks and libraries with asyncio support should be chosen whenever possible. > Overall there are also places where functions are async running in sync bodies, but they're not running on main thread. That would be a design mistake, as functions have colors[1] with async/await. That's currently my biggest gripe in the python ecosystem, apart from modules maintaining their own hidden state. [0]: https://docs.python.org/3/library/asyncio-task.html#asyncio.to_thread https://docs.python.org/3/library/asyncio-task.html#asyncio.... [1]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

deleted 2y ago

[deleted]

Retr0id 2y ago

Presumably, they would - hopefully, the work they're doing is quick enough that it doesn't really matter that they're blocking (this is usually true when interacting with sqlite, for example). Async request handlers are nice to have for when you do want to do something genuinely async (like firing off another HTTP request to somewhere else)

odie5533 2y ago

It looks like the author is mistakenly using the sync versions of SQLAlchemy calls. Unless it's on purpose. Either way, not a good sign.

wesselbindt 2y ago
I can't imagine someone having the chops to code up their own web framework and making a mistake like this. There must be something that we're missing. Another commenter suggested that since it's SQLite, the blocking calls are quick enough not to care, which may be true. I don't know enough about SQLite's performance characteristics to judge that. In general I assume disk I/O is slow enough (even on SSD) to care about blocking the event loop and delegating the calls to a thread. But I've been wrong about this before. For example, a call to stat is technically blocking, but the overhead of delegating it to a thread is actually more expensive (on my Framework 13) and blocks the loop longer than just doing the call outright in the main thread.
- anentropic 2y ago
  FWIW... CloudFlare Durable Objects rely on sync calls to SQLite being fast https://blog.cloudflare.com/sqlite-in-durable-objects/ https://blog.cloudflare.com/sqlite-in-durable-objects/