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.