After having a deeper dive into the documentation and examples, one pattern I see popping up quite frequently is this: future<R> fut = my_promise.get_future(); post_callback(some_work, [this](expected<R> r) { this->my_promise.set_value(r.get()); }); return fut;
This is simply to make examples easier to run (it finishes the example). It demonstrates that the only one which blocks in an application built on Asynchronous is main(). This might be more confusing than useful and I probably should get rid of this.
Is there any performance/usability drawback from this (might have gotten the syntax wrong here): return post_future(pool, some_work);
Why is the former to be preferred to the latter, or vice versa?
post_future is the preferred for simple applications or examples. It is similar to std::async (without the problem of blocking futures and with different continuations). post_callback is the design the library seeks to promote for bigger applications: post a task to a threadpool, get a callback posted to the queue of the caller's thread world.
Regarding the documentation overall, it seems to miss a proper reference section. For example, boost::asynchronous::expected is used almost everywhere, but not documented.
My bad. Will be corrected. Thanks, Christophe