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-11-30 15:28:36

On 11/30/2016 08:10 AM, Biddiscombe, John A. wrote:
> Christophe
>
>>
> I don't think the libraries have the same goals (or at least it seems to me so). Asynchronous is first of all an architecture tool focusing on organizing a whole application into thread worlds.
> <
>
> If I understand this correctly, then I'd say that that is what HPX does too. (I usually explain to others that OpenMP creates 'parallel regions', where code operates in tasks, whereas the whole of an HPX application is one enormous parallel region). I presume this is what you mean by 'thread worlds'
Not sure if I understand. Can you point me to some documentation or 
examples?

Disclaimer: my knowledge of HPX is limited to a quick glance at the doc. 
Feel free to correct my mistakes.

I understood HPX as a library returning futures to calls to asynchronous 
functions, somewhat similar to std::async.
In that case, the main region with all the futures would be a thread 
world for asynchronous. In huge applications, this does not solve the 
problem of organizing thousands of objects within threads.

>>
> The libraries also do not have the same design / tradeoffs. Asynchronous can make use of futures but encourages callbacks and tries to make these as safe as possible. The goal is to be as asynchronous (meaning non-blocking) as possible.
> <
>
> A future .then() or continuation is really just a type of callback too (broadly speaking).

Not really, if I understand correctly 
(http://en.cppreference.com/w/cpp/experimental/future/then). The functor 
object passed to then() is executed in an unspecified thread of 
execution, which makes it hard for the caller to (safely) pass data 
which might or might not be valid or relevant at the time the then 
functor executes.
I however could not find out whether this also applied to HPX.

This simple example, called within a state machine living within a 
thread world will help me show the difference:

post_callback(
     // task running in threadpool
     [](){/* long lasting task */},
     // callback
     [this](boost::asynchronous::expected<void>)
     {
       // if this is called, it is guaranteed that:
       // this executes within the thread context of the calling object
       // the calling object is still alive

       //----> we now decide what to do next
     }
);

As the callback executes within the calling object's thread context, we 
can choose at the callback execution time if we still want to call the 
code which we would call in the then(), and if we call, we do it with 
data relevant at this time, not at the time of the first call.

>>
> Future-based designs do not mix well with state machines' run-to-completion.
> <
>
> Could you elaborate a little on that comment please? I have a had a couple of instances where I'm manipulating 'state' and transitioning from one to another - I would welcome some ideas on how to make this a bit cleaner.

A future.then() returns another future so isn't it just delaying the 
fact  that I have to decide at some point what to do with the future 
object? Do I poll it, get() it or ignore it?
Polling is tedious, ignore usually wrong, and get() means blocking. As a 
state machine run-to-completion is supposed to execute in no time, this 
is not a good option.
Run-to-completion means: event is sent, transition is executed. Until it 
completes, the state machine is in an unstable state. This has to be 
kept as short as possible.

>>
> The reason for the non-blocking focus is that I'm using the library at work in an industrial 24/7 application. When working on the production line, blocking is a disaster. If an algorithm goes astray, or simply takes longer than usually, blocking the production line results in huge costs. Crashes due to races also. Asynchronous provides ways to avoid both.
> <
>
> I would say that non-blocking behaviour is one of the central goals of HPX. Continuations are only triggered when futures become ready and therefore blocking is avoided - so I don't think there's any disagreement there! Races are a problem, but a functional style of programming goes a long way to avoiding them.

I agree that HPX likely solves well the race problem, which is a great 
achievement.
I feel both libraries solve quite different problems. Asynchronous is 
focusing on organizing objects into threads and building everything else 
on top of that. In that context, callbacks within these object's thread 
contexts make more sense than a fire-and-forget of a future.then();

Which does not mean a fundamental disagreement with HPX, simply a 
different focus.

> Thanks for the reply - I'll be going through your repo looking for good ideas (and borrowing them).

I'd love it!
Thanks a lot for the feedback, I now see what things doc is missing 
(explanation of thread worlds, reasons for callbacks)

> Cheers
>
> JB
>

Cheers,
Christophe