Continuations run on the wrong thread about autobahn-cpp

[oberstet]

Specifically, then creates a new async thread that waits on the future, then runs the callback.

This is bad. I would first try to find out if the desired behavior can be achieved using some options or whatever: have continuations run on the main thread. I can't believe no one has stepped on this before.

Rgd switching API to callbacks: no, callbacks suck and quickly lead to unmaintainable spaghetti code. I'd rather write a pure C implementation then.

Rgd reinventing the wheel: no, I'd rather not invent a future class. This would greatly reduce interop with more async code (that would be using Boost's / C++11 stdlib futures)

[oberstet]

Can you retry what you did and specify a launch policy?

f1.then(boost::launch::deferred, ...)

• http://stackoverflow.com/questions/22934575/why-does-boostfuturetthen-spawn-a-new-thread
• http://stackoverflow.com/questions/25327256/execute-in-main-thread-with-boostfuturethen

[taion]

launch::deferred isn't going to work - that just means to run the continuation in-line when you ask for the result. Since many of these continuations are used as completion handlers, they don't produce usable results, and anyway you don't want to block the IO service thread to wait anyway. In general nothing in the standard futures is going to give the right behavior - the futures need to integrate tightly with the event loop; you can't infer from fulfilling a generic promise that the right thing to do is to run the continuations immediately in-line, because that's not generally the right thing to do in a multi-threaded system.

I put up a quick example here: https://github.com/taion/AutobahnCpp/commit/2f2f8b05680ad26c67981d063afeb928b202611b. Because the result of the session join continuation is never used, that continuation never gets run, and the output is only:

Running on 105700
Starting ASIO I/O loop ..
Connected to server

---

I think there are really 3 options here.

1. Use callbacks. This is my preferred solution. Nobody likes writing async code with callbacks, but the rest of the asio async function calls all use callbacks for completion handlers. Logically in many cases like for session::join or for making registrations, this is arguably more semantically correct anyway, since the use case you're trying to solve is to just attach a completion handler. It's the most consistent with the rest of asio async which most users of Autobahn|Cpp will be using anyway, so there already will be callback-based code, and it's pretty clear what's going on.
2. Use a custom future class. You've already outlined the downsides above - this is potentially very fragile.
3. Use coroutines: http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/overview/core/spawn.html. This should give you more readable code than using callbacks, and is most likely going to work as desired, but I've never heard of anybody using coroutines in C++, and it's going to seem relatively "magical" to most developers. It does make things look more like how they'd look in Python, though.

---

I really think the callbacks are the best option here. They're not ideal ergonomically, but it fits in with the rest of asio async, so at the margins you're not making things that much worse, and the other solutions are all much harder for the user to understand, which I think matters as much as making them easy to use.

[jpetso]

Preparing for C++1z, asio is making its io_service (recently renamed to io_context in asio master) into an Executor. That means it'll be possible to call future.then(io_service, lambda); but the downside, or bad news, is that asio in boost is not an Executor yet.

The cppwamp issue referenced above is putting a wrapper on top of io_service so it'll work as an Executor, with a bit of luck that should work for AutobahnCpp as well.

[taion]

I've long since switched to cppwamp, and given the amount of movement here since, I suspect this is no longer relevant. Closing for staleness.

[ecorm]

Asio was updated in Boost 1.66 release. There's mention of executors in this new documentation page: http://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/net_ts.html

I'm too busy with work/life right now to investigate any deeper. Coroutines and the traditional callback interface have been working well for us so far at work; we don't use use futures.