Endpoints returning futures don't work

[taion]

From #21. Apologies for the formatting.

---

@taion #21 (comment):

Actually, it turns out that none of the endpoints that expect futures actually work. The issue is that you actually wait on the future here:

https://github.com/tavendo/AutobahnCpp/blob/b44ee2e0582923fe8e175eff1ec726582575f4e2/autobahn/autobahn_impl.hpp#L771

However, this ends up blocking the running thread. If my endpoint does something like

return session.call(procedure, args).then(/* do some work*/);

then the procedure will never actually return, because the running thread is blocked on the done.wait() call, and cannot process the return value from the called procedure and resolve the future.

You can't wait for the future to be resolved there.

---

@oberstet #21 (comment):

Here is an example for endpoint_fvm_t: https://github.com/tavendo/AutobahnCpp/blob/master/examples/register2.cpp#L63

---

@taion #21 (comment):

The reason that example works is because the future is ready, so done.wait() returns immediately.

If waiting for the future actually requires handling some input (e.g. you invoke another method and wait for it to finish), then it will not work, because you've blocked the main thread from actually processing the response.

---

@oberstet #21 (comment):

I see.

I guess it would be good if we first had an example that demonstrates the issue, and then come up with a solution.

This is the harder problem - extending the solution to the variants should then be straightforward.

---

The issue with variants is no longer there, but endpoints that return futures still don't work. Some combination of boost::asio::io_service::work and std::shared_ptr will probably be required to resolve this.

[davidchappelle]

This is fixed in my fork of autobahn-cpp. Also, the only reason that the examples even work is due to the fact that the boost tcp resolver actually creates a thread that polls the io service.

[taion]

@davidchappelle Cool - I've actually switched to CppWAMP, but probably having a working "official" AutobahnCpp implementation is a good thing.

[davidchappelle]

This can now be closed.