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

Subject: Re: [boost] Asynchronous library now in Boost Library Incubator
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2016-12-07 15:29:04

On 12/07/2016 03:59 PM, Thomas Heller wrote:
> 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?

I mean longer waiting due to future not being set.

> 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 ;)

Yes. We both follow the same goal, removing programmers out of harm way 
through direct thread access.

>>
>>> 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.

I will improve the doc and examples in the next days to make it clearer.

BTW I just improved our first example (the task in 2 parts) by making 
some more threads access the proxy. It shows there is no life issue, the 
last thread holding the last proxy to an object from a thread world will 
shut the thread world down.
I think it is a powerful design feature. Software is usually designed in 
components, which one tries to make reusable. This is usually difficult 
because of thread issues (in which thread context did we use this thing 
in the last project? Its own? Another one? Who shut it down?). This 
problem is now gone. The component represented by one (or several) proxy 
is safe, completely reusable and its thread limits are well defined (and 
irrelevant for the software using the component). This turned out in 
real code to be a life saver.

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

Yes, I'll probably follow your advice, I'm not happy about github.io either.

Thanks for the interesting discussion.