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
}