On Wed, 22 Sept 2021 at 19:40, Peter Dimov via Boost
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