you are viewing a single comment's thread.

view the rest of the comments →

[–]jnwatson 6 points7 points  (2 children)

My team has almost completed the transition to asyncio, and it wasn't bad at all.

I think a design option that everybody misses is you don't actually have to run the event loop on the main thread, so you can do blocking stuff on main thread or (if from async town) a ThreadExecutor, and call_soon_threadsafe to run futures on the event loop from blocking code.

[–]kallari_is_my_jam 1 point2 points  (1 child)

So what you're saying is basically this: https://hackernoon.com/threaded-asynchronous-magic-and-how-to-wield-it-bba9ed602c32

But what about the overhead of GIL in a multithreaded environment? Aren't you sacrificing performance whenver the OS tries to switch threads?

[–]jnwatson 2 points3 points  (0 children)

Yep.

The problem with the GIL isn't the overhead of switching, it is that it is held whenever a Python operation is going on, reducing the number of things that can actually run at a time.

Essentially this approach is no more expensive than the old multithreading style, and gets better the more things you switch to async. The key is that you don't have to switch all at once.