<story><title>How Python asyncio works: recreating it from scratch</title><url>https://jacobpadilla.com/articles/recreating-asyncio</url></story><parent_chain></parent_chain><comment><author>kodablah</author><text>Asyncio allows you to replace the event loop with an implementation of your own. For Temporal Python we represent workflows as a custom, durable asyncio event loops so things like asyncio.sleep are durable timers (i.e. code can resume on another machine, so you can sleep for weeks). Here is a post explaining how it&amp;#x27;s done: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;temporal.io&amp;#x2F;blog&amp;#x2F;durable-distributed-asyncio-event-loop&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;temporal.io&amp;#x2F;blog&amp;#x2F;durable-distributed-asyncio-event-l...&lt;/a&gt;.&lt;p&gt;The biggest problem with asyncio is how easy&amp;#x2F;common it is in Python to be able to block the asyncio thread with synchronous calls, gumming up the whole system. Python sorely needs a static analysis tool that can build a call graph to help detect if a known thread-blocking call is called directly or directly from an async def.</text></comment>
<story><title>How Python asyncio works: recreating it from scratch</title><url>https://jacobpadilla.com/articles/recreating-asyncio</url></story><parent_chain></parent_chain><comment><author>krackers</author><text>This seems to &amp;quot;busy wait&amp;quot; when sleeping, i.e. the event loop keeps running even if nothing is currently runnable. I remember reading about another toy implementation which handled it correctly (the way I believe it&amp;#x27;s actually done in asyncio) by tracking the next-runnable times of a task in sorted order, and if nothing is currently runnable you can sleep the event loop. And then this was extended so that instead of just next-runnable depending on wall-clock time, the task could have a dependency on a socket or something, so that you can use select w&amp;#x2F;timeout.</text></comment>