Boost asio io_service dispatch vs post

南笙酒味 提交于 2019-11-29 22:48:43

Well, it depends on the context of the call, i.e. is it run from within the io_service or without:

  • post will not call the function directly, ever, but postpone the call.
  • dispatch will call it rightaway if the dispatch-caller was called from io_service itself, but queue it otherwise.

So, it depends on the function calling post/dispatch was called, and if the given handler can be called straight away or not.

What this means:

... is that dispatch might eventually call your code again (naturally, this depends on your app and how you chain calls), but in general you should make sure your callback is re-entrant if you use dispatch.

dispatch is thus faster, as it avoids queueing the call if possible. It comes with some caveats, so you might want needs to use post occasionally, or always (if you want to play it safe and can afford it).

Update

To incorporate some from @gimpf 's deleted answer, an older boost version had this implementation of dispatch (my comments):

template <typename Handler>
void dispatch(Handler handler)
{
  if (call_stack<win_iocp_io_service>::contains(this)) // called from within io_service?
    boost_asio_handler_invoke_helpers::invoke(handler, &handler); // invoke rightaway
  else
    post(handler); // queue
}

see this blog entry:
To post or to dispatch? - This Thread

Running the application we'll see the difference between posting and dispatching. Since it could do it, dispatch() would execute fB() directly, so we'll see it runs in the current thread, and synchronously. On the other side, post() would ask to io_service to do the job, asynchronously in another thread, and it immediately returns the control to the caller.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!