2

I would like to know how I should understand boost::asio::post

In particular this overload that can just take a single callable, who/what/where executes it now (since I don't explicit pass it an io_service/io_context for example) ?

Does it just randomly (more or less) choose a running io_service (if there is one) ? I feel like there is something Im completely missing.

darune
  • 10,480
  • 2
  • 24
  • 62
  • 1
    It does say _"Obtains the handler's associated executor object `ex` by performing `get_associated_executor(handler)`"_ at the bottom of your own link. Does that answer the question? If not, are you really just asking what `get_associated_executor` returns? – Useless Oct 13 '20 at 11:36

2 Answers2

4

Eventually, boost::asio::post will use get_associated_executor to look up a specialization of associated_executor. The default implementation will provide a static instance of system_executor, where the object will be invoked.

Dave S
  • 20,507
  • 3
  • 48
  • 68
  • It does leave me wondering still, I do not know about system_executor or associated_executor - parhaps, can you elaborate a bit more ? – darune Oct 13 '20 at 11:38
  • also system_executor does sound unsuitable for my purpose as it mentions a thread pool, I need everything to run on same thread (thus avoiding sync'ing) ! – darune Oct 13 '20 at 11:41
  • @darune May be you simply need to learn the basis of asio ... [Best documentation for Boost:asio?](https://stackoverflow.com/questions/244453/best-documentation-for-boostasio) – Jean Davy Oct 14 '20 at 06:41
  • @Darune I've personally never had a use case for the single argument version of `post`, as I always want to specify the executor to run on. It seems to exist when you want to route certain handlers to static executors based on type. Obviously the implementors of ASIO felt it was something useful. Getting into how to use ASIO more fully is a bit beyond the scope of a single Stack overflow question. – Dave S Oct 14 '20 at 12:00
  • @DaveS Thanks, I see, I also ended up using that version - the single argument would perhaps be more usefull if it guarendteed same thread/io_context (or that would be a configuration) – darune Oct 15 '20 at 08:36
1

Dave S's answer is correct, but if a writer of the code is confused with the default signature, imagine what will happen to a reader! Maybe better to just use this or this overload with explicit execution context argument instead.

bobah
  • 18,364
  • 2
  • 37
  • 70
  • 1
    I've +1-ed this for _mentioning_ the explicit executor overloads. Don't forget, though, that in many cases the implicit "magic" behaviour (with associated executors) is precisely what you /want to/ have (e.g. when the task is a strand-wrapped completion handler, and you can't know which strand it belongs to. This is where associated executors become very powerful) – sehe Oct 19 '20 at 15:17