Comment by camgunz

Comment by camgunz a day ago

Oh no you're right it's a pain in the ass and weird. But I think it's the way because there's no good reason to have more than one event loop.

Also... maybe it started out as generator wrappers? I think I read something that said that.

Spivak a day ago

> no good reason to have more than one event loop

Per thread—once you start working in multiple threads you have the choice to have one global event loop, which comes at the cost of all async code being effectively serialized as far as threads are concerned*, or one event loop per thread.

* Which can be fine if your program is mostly not async but you have that one stubborn library. Yay async virality.

Reply View 5 replies

camgunz a day ago

I can't say there's no good reason to have per thread event loops, but I think I can say if you do know of one you're suffering a terrible curse. I can only imagine the constraints that would force me to do this.

Reply View | 4 replies
- Spivak a day ago
  
  Because you have a main application running a web server and a daemon worker thread performing potentially long running tasks that use async libraries and you don't want to block the responsiveness of your web server. It's really not that bad, at least in Python.
  
  Reply View | 3 replies
  
  camgunz a day ago
  
  Well, here we go I guess. Why can't you just use FastAPI? Or Tornado? Isn't there also an async Flask? Isn't Django also async now? What minor god have you angered to be chained to a non-async framework?
  
  Reply View | 2 replies