Brief guide to migration from Autobahn|Cpp?

[Jimmy Jia]

Hello,

I'm looking to migrate a small project from Autobahn|Cpp to CppWAMP due to issues with how async processing is handled in Autobahn|Cpp (https://github.com/tavendo/AutobahnCpp/issues/42, https://github.com/tavendo/AutobahnCpp/issues/43) that likely will require breaking API changes to resolve. While it seems straightforward enough to make the migration, it might be nice to have a brief guide describing how to do so nevertheless.

Thanks,

Jimmy Jia

[Emile Cormier]

A migration guide would be nice indeed! But I have no experience using Autobahn|Cpp (other than running the example C++ programs), so I might not be the best person to write such a guide.

If you're willing to write one, let me know. The best place for the guide would be in CppWAMP GitHub wiki. Perhaps we could try the workflow suggested here: http://stackoverflow.com/questions/10642928/how-to-pull-request-a-wiki-page-on-github ?

I'll take a closer look at the issues you cited and will make sure they don't occur in CppWAMP as well. I'm glad that I used the "mixin" approach for the session API: a basic asynchronous API as the foundation, with a coroutine API layered on top of it. I plan on using the same approach for adding support for Boost futures.

Please be advised that I have a new release coming up (0.3.0) that will break the API a little. It should be released sometime this evening or tomorrow.

Cheers,

Emile

[Jimmy Jia]

The CppWAMP APIs essentially match the asio async APIs, no? I decide whether to pass in a handler, a yield context, or asio::use_future, and the appropriate thing happens in all cases.

I'll take notes on anything non-trivial I do during migration. If it's trivial enough, maybe there is no need for such a guide after all.

The concurrency issues with Autobahn|Cpp only arise with futures, and only if you're using the experimental boost::future::then for futures derived from boost::promise. This is the way the Autobahn|Cpp examples use the futures, and it doesn't work if you care about thread-safety.

Unfortunately non-thenable futures are pretty sad, since the only thing you can really do is to block on them, which defeats the point a bit. There's nothing wrong with having futures for completeness to mirror asio's API, but you can see even from the asio examples that they're a lot more painful to work with than either callbacks or coroutines.

--
You received this message because you are subscribed to the Google Groups "CppWAMP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cppwamp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cppwamp/2f58d55d-6987-4ac0-9c83-d3d16469d858%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emile Cormier]

On Wednesday, April 22, 2015 at 6:25:13 PM UTC-3, Jimmy Jia wrote:

The CppWAMP APIs essentially match the asio async APIs, no? I decide whether to pass in a handler, a yield context, or asio::use_future, and the appropriate thing happens in all cases.

It's not that simple, unfortunately. You can't pass a yield context to a Session operation that expects an async callback. If you want to pass a yield context, you have to use CoroSession.

CoroSession inherits from Session, so you can work with both coroutine and callback APIs from the same CoroSession object (thanks to overloading). I've done so in a few of my test cases.

 

The concurrency issues with Autobahn|Cpp only arise with futures, and only if you're using the experimental boost::future::then for futures derived from boost::promise. This is the way the Autobahn|Cpp examples use the futures, and it doesn't work if you care about thread-safety.

Please note that I haven't yet put any consideration into multi-threading. The embedded system I'll be using CppWAMP on is single-core, so it wasn't much of a concern for me. In particular, the Session member functions are non-reentrant because they reuse premade WampMessage objects (in an effort to reduce the number of memory allocations).

Theoretically, there should be nothing preventing two independent Session objects from executing concurrently, but I haven't taken any time to verify if that's indeed the case.

[Jimmy Jia]

From a user perspective, having the overloads available on CoroSession sounds close enough to me. I probably won't actually be using the coroutines anyway.

I'm also planning on only using a single-threaded event loop. The problem with futures was that the continuations would actually not be processed in my single event loop thread, and that it wasn't possible without significant additional work to make them behave in that manner.

--

You received this message because you are subscribed to the Google Groups "CppWAMP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cppwamp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cppwamp/252a1da7-896b-4c05-9db9-42d8469b974c%40googlegroups.com.