Re: [boost] Asynchronous library now in Boost Library Incubator

Subject: Re: [boost] Asynchronous library now in Boost Library Incubator
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2016-12-07 09:59:58

On 12/06/2016 11:44 PM, Christophe Henry wrote:
>> Don't get me wrong, I'm not really trying to say that libraries like hpx,
>> or boost.thread or folly or ppl solved your problem. I was trying to
>> demonstrate that futures, async and friends are not your enemies, on the
>> contrary.
> 
> I think they are your friends ;-)
> Mine are callbacks. Blocking futures are my enemies. I'm still unsure
> whether there is such a thing as a non-blocking future.

What exactly do you mean by blocking? Logical blocking as in P0296R0?
Suspending the execution context for waiting until the result is ready?
Possible suspension of the running threads due to contention in the
synchronization with the shared state?

If it is the suspension until the asynchronous task returned the result,
then yes, this is exactly what the Concurrency TS is trying to solve. By
allowing to attach continuations to futures. The future that is passed
to the continuation is guaranteed to be ready. The future in the
continuation (attached with .then) behaves exactly as your expected.

Something like your continuation construct is perfectly doable without
blocking (that is suspending until the result is set) on futures.
co_await nicely integrates with futures such that you never actually
need to suspend and code using continuations/callbacks gets much
cleaner. callback based mechanisms, be it either through .then or your
mechanism, will never, ever be as performant or elegant without co_await.

Anyway ... using futures or not is not really the point of your library.
It's just a matter of how you skin your cat. Of course, a current
std::future can not meet those requirements. boost::future can (and many
others already mentioned in this thread ;)). A future, in the end, is
just a mechanism to transport the result of an asynchronous operation.
You chose to solve that in a different manner, so be it. We can agree to
disagree on how to skin the cat ;)

> 
>> Regarding the layered example, I'm still trying to understand the
>> semantics
>> of your different APIs. There are a lot of things doing the same from a
>> different perspective (proxy, servant, scheduler).
> 
> Sorry about that. One of the reasons for starting discussing the library
> before the review is that my team and I are using the library since so
> long that we're not seeing any more what others do not understand. Thank
> you for your help pointing me the difficulties.
> I clearly have to make this clearer in the doc.
> 
> A scheduler = I suppose, roughly your executor.
> 
> The next two: see Active Object Pattern Gang of Four.
> The names are chosen as to correspond to the pattern.
> 
> A servant = an thread-unsafe object like the manager of our example,
> living into a single-thread-scheduler.
> A servant proxy = A thread-safe object behaving like the servant it
> represents, for usage by outside threads.

Ok, it all starts to get clearer now, and the purpose of the library is
starting to materialize in my head. I understand the motivation better
now. I am not sure yet if I like that concept ;)
Thanks for the clarifications.

NB: You should consider using github pages to serve your documentation
instead of this htmlpreview.github.io thingy. Works much smoother.