3 ms·

Can you provide any links on references to a memory model for async calls, I would be interested in reading them.

Matthias247 7y ago
I actually have't heard of any - and I'm pretty deep into the async things. Rusts async model just follows the synchronous model. Everything is not thread-safe unless it's annotated with the `Send` or `Sync` annotation. Futures which can be awaited are either not thread-safe - which means they can only be executed by a single threaded executor. If they are `Send` they can be migrated between threads and also executed by a multithreaded executor - like tokio. But those are rather just thread-safety annotations and not a memory-model
jreyes33 7y ago
They might be referring to `Pin`. See https://doc.rust-lang.org/stable/std/pin/index.html https://doc.rust-lang.org/stable/std/pin/index.html and also https://rust-lang.github.io/async-book/04_pinning/01_chapter.html https://rust-lang.github.io/async-book/04_pinning/01_chapter...
tmandry 7y ago
I’m not sure I would call this a memory model per se, but here’s how async tasks are laid out in memory. http://tmandry.gitlab.io/blog/posts/optimizing-await-1/ http://tmandry.gitlab.io/blog/posts/optimizing-await-1/
xiphias2 7y ago
I was referring to the fact that it is the only async implementation that I know of that compiles to a state machine that doesn't need to allocate new memory for each continuation. I think it will translate to extremely fast web services in practice. Pinning is of course part of the elegant solution. There are some great videos about it: https://www.youtube.com/watch?v=lJ3NC-R3gSI&t=1710s https://www.youtube.com/watch?v=lJ3NC-R3gSI&t=1710s https://www.youtube.com/watch?v=skos4B5x7qE https://www.youtube.com/watch?v=skos4B5x7qE
- majewsky 7y ago
  > I think it will translate to extremely fast web services in practice. In practice, it's probably not going to matter all that much because the average web service does way more time-expensive things like disk IO or SQL queries. The more significant effect is that async-await being really really fast enables you to use it in more places. For example, if you have a tight computation loop where different aspects of the logic are meshed together in a hard-to-read way, now you could try detangling it into several async actors talking to each other to make it more readable, without utterly destroying the performance characteristics.

I actually have't heard of any - and I'm pretty deep into the async things. Rusts async model just follows the synchronous model. Everything is not thread-safe unless it's annotated with the `Send` or `Sync` annotation. Futures which can be awaited are either not thread-safe - which means they can only be executed by a single threaded executor. If they are `Send` they can be migrated between threads and also executed by a multithreaded executor - like tokio. But those are rather just thread-safety annotations and not a memory-model

jreyes33 7y ago

They might be referring to `Pin`. See https://doc.rust-lang.org/stable/std/pin/index.html https://doc.rust-lang.org/stable/std/pin/index.html and also https://rust-lang.github.io/async-book/04_pinning/01_chapter.html https://rust-lang.github.io/async-book/04_pinning/01_chapter...

tmandry 7y ago

I’m not sure I would call this a memory model per se, but here’s how async tasks are laid out in memory. http://tmandry.gitlab.io/blog/posts/optimizing-await-1/ http://tmandry.gitlab.io/blog/posts/optimizing-await-1/

xiphias2 7y ago

I was referring to the fact that it is the only async implementation that I know of that compiles to a state machine that doesn't need to allocate new memory for each continuation. I think it will translate to extremely fast web services in practice. Pinning is of course part of the elegant solution. There are some great videos about it: https://www.youtube.com/watch?v=lJ3NC-R3gSI&t=1710s https://www.youtube.com/watch?v=lJ3NC-R3gSI&t=1710s https://www.youtube.com/watch?v=skos4B5x7qE https://www.youtube.com/watch?v=skos4B5x7qE

majewsky 7y ago
> I think it will translate to extremely fast web services in practice. In practice, it's probably not going to matter all that much because the average web service does way more time-expensive things like disk IO or SQL queries. The more significant effect is that async-await being really really fast enables you to use it in more places. For example, if you have a tight computation loop where different aspects of the logic are meshed together in a hard-to-read way, now you could try detangling it into several async actors talking to each other to make it more readable, without utterly destroying the performance characteristics.