Boost logo

Boost :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2021-09-22 17:49:55


On Wed, 22 Sept 2021 at 19:40, Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Niall Douglas wrote:
> > 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.
>

There is another strategy in common use in financial markets, in which the
total memory footprint is allocated up front on program start.
The technique is in production use with ASIO in such applications as
commodity and stock exchanges.
The total amount of memory per connection is known up front, as is the
total number of allowed simultaneous connections.
Asio can take advantage of this as Niall mentioned, by associating a custom
allocator with the IO executor and the handlers of asynchronous operations.
The net effect is zero allocations and no thread synchronisation (most
matching engines run in a single thread in a hot loop with kernel-bypass
network drivers).
All this functionality is available out of the box, with the exception of
the custom allocator, which you would need to write yourself to suit your
chosen memory recycling strategy.

>
> Hypothetically, what Andrzej was asking for was: he gives Asio a movable
> state object and a movable completion handler, Asio puts these somewhere,
> initiates the async op, doesn't move them in the meantime, when the async
> op completes invokes the handler, passing it the address of the state
> object,
> the handler then either moves the state back somewhere, or gives it back
> to Asio for the next async call.
>
> This looks doable, although in practice probably won't gain much.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk