<story><title>Inside Rust&apos;s Async Transform</title><url>https://blag.nemo157.com/2018/12/09/inside-rusts-async-transform.html</url></story><parent_chain><item><author>2bitencryption</author><text>Async&amp;#x2F;await pattern always confuses me, someone please let me know if I get this right:&lt;p&gt;First, async&amp;#x2F;await does NOT mean &amp;quot;threading&amp;quot; or &amp;quot;multiprocessing&amp;quot; or &amp;quot;concurrency&amp;quot;.  It simply means &amp;quot;using a state machine to alternate between tasks, which may or may not be concurrent.&amp;quot;  Right?&lt;p&gt;Further, in Javascript, futures and async are utilized heavily because we so frequently need to wait for IO events (i.e.: network events) to complete, and we don&amp;#x27;t want to block execution of the entire page just to wait for a IO to complete.  So the JS engine allows you to fire off these network events, do something else in the meantime, and then execute the &amp;quot;done&amp;quot; behavior when the IO is complete (and even in this case, we might not be concurrent, because ).&lt;p&gt;That makes sense to me.&lt;p&gt;But say I have written something in Rust that makes use of async&amp;#x2F;await.  And say there is absolutely no IO or multithreading.  Say I have some awaitable function called &amp;quot;compute_pi_digits()&amp;quot; that can take arbitrarily long to complete but does not do IO, it&amp;#x27;s purely computational.  Is there any benefit to making this function awaitable?  Unless I actually spawn it in a different thread, the awaitable version of this function will behave identically to if it were NOT awaitable, correct?&lt;p&gt;And one last idea: the async&amp;#x2F;await pattern is becoming so popular across vastly different languages because it allows us to abstract over concepts like concurrency, futures, promises, etc.  It&amp;#x27;s a bit of a &amp;quot;one size fits all&amp;quot; regardless of whether you&amp;#x27;re spinning up a thread, polling for a network event, setting up a callback for a future, etc?</text></item></parent_chain><comment><author>ben0x539</author><text>I think the JS world might be particularly excited about async&amp;#x2F;await because other people just escape to threads when they don&amp;#x27;t want to block the whole thing on IO.&lt;p&gt;Both in JS or Rust, you don&amp;#x27;t gain anything just by declaring your thing to be async, or awaitable. Your function needs to be built around some kind of &amp;quot;primitive&amp;quot; that explicitly supports the &amp;quot;do something else in the meantime&amp;quot; mechanism. Using &amp;quot;await&amp;quot; on that thing lets your function piggyback on its support, but all your explicit, normal code is synchronously blocking as usual.&lt;p&gt;In Rust, I think it&amp;#x27;s a fairly established pattern to turn blocking code, where the blocking part is not some IO action that has explicit support for the futures mechanism, into a asynchronous, awaitable function by punting the work to a threadpool. That makes sense for CPU-bound work as well as IO done by libraries that don&amp;#x27;t support futures or things like disk IO where the OS might not actually have decent support for doing it in a non-blocking fashion.&lt;p&gt;I&amp;#x27;m not sure if it&amp;#x27;s the canonical mechanism, but this crate seems to implement what I&amp;#x27;m thinking of: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.rs&amp;#x2F;futures-cpupool&amp;#x2F;0.1.8&amp;#x2F;futures_cpupool&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.rs&amp;#x2F;futures-cpupool&amp;#x2F;0.1.8&amp;#x2F;futures_cpupool&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Inside Rust&apos;s Async Transform</title><url>https://blag.nemo157.com/2018/12/09/inside-rusts-async-transform.html</url></story><parent_chain><item><author>2bitencryption</author><text>Async&amp;#x2F;await pattern always confuses me, someone please let me know if I get this right:&lt;p&gt;First, async&amp;#x2F;await does NOT mean &amp;quot;threading&amp;quot; or &amp;quot;multiprocessing&amp;quot; or &amp;quot;concurrency&amp;quot;.  It simply means &amp;quot;using a state machine to alternate between tasks, which may or may not be concurrent.&amp;quot;  Right?&lt;p&gt;Further, in Javascript, futures and async are utilized heavily because we so frequently need to wait for IO events (i.e.: network events) to complete, and we don&amp;#x27;t want to block execution of the entire page just to wait for a IO to complete.  So the JS engine allows you to fire off these network events, do something else in the meantime, and then execute the &amp;quot;done&amp;quot; behavior when the IO is complete (and even in this case, we might not be concurrent, because ).&lt;p&gt;That makes sense to me.&lt;p&gt;But say I have written something in Rust that makes use of async&amp;#x2F;await.  And say there is absolutely no IO or multithreading.  Say I have some awaitable function called &amp;quot;compute_pi_digits()&amp;quot; that can take arbitrarily long to complete but does not do IO, it&amp;#x27;s purely computational.  Is there any benefit to making this function awaitable?  Unless I actually spawn it in a different thread, the awaitable version of this function will behave identically to if it were NOT awaitable, correct?&lt;p&gt;And one last idea: the async&amp;#x2F;await pattern is becoming so popular across vastly different languages because it allows us to abstract over concepts like concurrency, futures, promises, etc.  It&amp;#x27;s a bit of a &amp;quot;one size fits all&amp;quot; regardless of whether you&amp;#x27;re spinning up a thread, polling for a network event, setting up a callback for a future, etc?</text></item></parent_chain><comment><author>kaeso</author><text>&amp;gt; Is there any benefit to making this [compute_pi_digits()] function awaitable?&lt;p&gt;If you introduce suspension points in that (e.g. every 100 computed digits), then you can co-schedule other tasks (e.g. a similar `compute_phi_digits`) or handle graceful cancellation (e.g. if a deadline is exceeded, or its parent task aborted in the meanwhile).</text></comment>