On 22/09/2021 15:39, Andrzej Krzemienski via Boost wrote:
I wonder if heap allocation is a necessary consequence of asynchronous computations, or is it only the choice of the interface in ASIO.
Internally ASIO will dynamically allocate additional state to store async ops in flight. Upon completion, those go into a free list and are reused. You cannot stop ASIO doing at least some form of dynamic memory allocation, albeit you can mitigate it using a custom Allocator. But to answer your question more generally, it is quite hard to avoid heap allocation for asynchronous *anything*. As Vinnie pointed out, you can't move state while something async is occurring. So there are two choices, either you use heap allocation or something gives you an opaque handle and you store that opaque handle in a map to state, which is probably a heap allocation. Sender-Receiver can avoid all heap allocations, but the price is you must invert your program design to use Sender-Receiver by describing all possible control flow paths at compile time, and that feels most unnatural plus it requires lots of typing. It's also an exact inversion of design from ASIO, which is based around code dynamically reacting to i/o state changes, whereas Sender-Receiver involves traversing a static state transition graph. They are chalk and cheese. Taking a bigger picture again, OS kernels almost always allocate memory inside the kernel for async i/o, whereas they usually can avoid it for blocking and non-blocking i/o. This is why blocking i/o can perform better than async i/o in some circumstances, because the kernel doesn't call its internal malloc. So I'd say there is a strong, but not fixed, correlation between async anything and dynamic memory allocation, in general. Niall