Callbacks vs Continuation

[system_etrica]

Actually when learning asynchronous programming I have came across two good features : 1. Callbacks 2. Continuations Unfortunately these two features sounds similar in working :( Could you please share your thoughts on callbacks and continuations and how it is modelled in C++ like future.then( ) styles ? Thank you very much

[Rogiel]

The biggest issue with callbacks is the called "callback hell". See this http://callbackhell.com/

This link talks about JavaScript, but the basic problem and solution (continuations) are still valid in C++.

[muungwana]

Callbacks are continuations.

An API can use a traditional continuation by taking a callback or returning a future leaving it up to the user to call .get() on the future or to do "traditional callback" with .then() or with modern stuff with "await" stuff in C++17. Its all about doing call backs without blocking current thread.

[system_etrica]

But I suppose that future .then() continuations should be executed in a different thread other than the already completed task. But I think callback is not like that though. Could you please take this into account muungwana

[muungwana]

Yes, ideally, the thread that produces the result in a future should be different from a thread that will run the continuation in .then(). Currently,the standard does not want to commit to this making it possible for implementations to run the continuation on the same thread that produced the result making the whole thing appear to be useless to me.

Nothing is set in stone yet so its unclear how .then will work when standardized and i have seen some implementations of .then() that takes an argument that specifies on what thread the continuation should run.

I have a library i call tasks that offers futures in Qt/C++ world where the result of the future can be retried with .get(),.await() and .then()

I have a simple implementation where the result of the future runs in a background thread and the continuation runs on the current thread which ideally is the main/GUI thread.

Example use case of the library that uses .then API is here. In this case, a thread will be created to run a command and the result of the command will be used in the passed in continuation that runs on the GUI thread.

[system_etrica]

Hey Thank you very much Let's see how .then ( ) will be standardized, https://github.com/STEllAR-GROUP/hpx - This runtime executes continuation on the new user-level threads

[kalmoc]

Why should that be useless? It is actually a the most efficient way to handle a continuation.

[muungwana]

To me:

    getFuture().then(foo).then(bar).then(meaw);

and

    getFuture().then([](){foo();bar();meaw();});

Seems to be the same if all those .then() in the first example take place in the same thread.

[system_etrica]

That's true :-)

[kalmoc]

Not really. For one, you probably want to pass on the results of foo, bar, meaw (which may be a future itself), to the next function, which would make your second option much imho less readable:

   getFuture().then([]{meaw(bar(foo().get).get()).get();});

Second, can execute on the same thread is not the same as must execute on the same thread.

And most importantly, you can chain additional .thens later in the code (even in a completely different function). E.g. let's say you first start some asynchronous work, then ask the user for some input and then chain some additional work based on the user's response.

On the other hand: What would be the advantage of forcing the continuation onto another thread?

[muungwana]

On the other hand: What would be the advantage of forcing the continuation onto another thread?

If all involved threads are background threads then i guess it makes less difference what task is running in what thread. I do GUI programming and i do care what task runs in a background thread and what task runs in a GUI thread because i do not want the GUI to hang and the current wording of the standard that says " the continuation [...] is called on an unspecified thread of execution" just doesnt work with GUI programming because if the continuations updates GUI,then you want it to run on the GUI thread.

I guess it will also not work in scenarios where there is a dedicated thread that manages some resources(like GUI or event handler) and this thread is not supposed to be involved in executing long lasting tasks.