While using boost::asio 1.66 I read in the documentation that boost::asio::io_context::post
is deprecated for boost::asio::post
, same for boost::asio::io_context::dispatch
. Because before they where member functions of the io_context
before, and of course the handler needs to be executed in the context of some io_context
i.e. executor
my question is:
How does boost::asio::io_context::post simplest overload know which io_context
i.e. executor
to use?
The documentation of template< typename CompletionToken> DEDUCED post(CompletionToken && token);
states that
Obtains the handler's associated executor object ex by performing get_associated_executor(handler).
But the documentation of get_associated_executor
does not make it clear to me either. My guess is due to the Template argument deduction it can grab it somehow in the currently executed handler, but I want to make sure and also, this wouldn't suffice if I call post
outside of a boost::asio handler.
The core of the documentation is found with the
associated_executor
trait:If your handler type¹ has a nested
executor_type
type, then it is assumed that callingtoken.get()
will return the correct executor to use.If you pass a vanilla calleable to post without specifying an executor/execution context you will get a default-constructed instance of an execution context:
boost::asio::system_executor
.The purpose of this is for the implementation to DoTheRightThing with custom handler types. E.g. if you post something on a strand, the handler will be wrapped in a type specific to the strand implementation. The
associated_executor
trait and dittoget_executor()
member function will then coordinate to direct to the executor for that strand.¹ or any token, in case your call model is different, like a yield context