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.