Boost logo

Boost :

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-09-22 16:43:04

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at