Skeleton parameters async API

[esteve]

Connects to ros2/ros2#28

@dirk-thomas @tfoote @wjwwood

[dirk-thomas]

Is this file missing from the PR?

[esteve]

Just pushed, sorry!

[tfoote]

+1

[dirk-thomas]

Year should be 2015.

[esteve]

Done.

[dirk-thomas]

Beside the minor comments the API looks good to me.

[esteve]

@dirk-thomas thanks for the feedback!

[wjwwood]

This signature left me with some questions, which might just be solved with documentation:

• Why does the callback receive the future and not just the value?
  • I guess because the future could result in an exception?
• Is the expectation that the call to future.get() in the user's callback will either raise or return the value without blocking (is the future always ready when the callback is called)?
  • Put another way, can the call to future.get() block in the user's callback?
• What happens if the user doesn't call .get() on the future?

[esteve]

Why does the callback receive the future and not just the value?
I guess because the future could result in an exception?

That is correct, get() will either raise a std::future_error exception or return the value.

http://en.cppreference.com/w/cpp/thread/future/get
http://en.cppreference.com/w/cpp/thread/future_error

Is the expectation that the call to future.get() in the user's callback will either raise or return the > value without blocking (is the future always ready when the callback is called)?
Put another way, can the call to future.get() block in the user's callback?

When the callback is fired, the std::future is already ready. In the previous version of the parameters API or in the current code for services (https://github.com/ros2/rclcpp/blob/master/rclcpp/include/rclcpp/client.hpp#L121), the value for the related std::promise is set before firing the callback.

What happens if the user doesn't call .get() on the future?

The callback function will be fired, but the user won't have access to the result of the operation.

[wjwwood]

That all sounds find to me. Thanks.

The callback function will be fired, but the user won't have access to the result of the operation.

Ok, I was more wondering if the future's (or the value in the future's) lifecycle was dependent on .get() being called, but I guess it doesn't.

I was also just now wondering if an exception could be silently suppressed if the user never calls .get() and if we could do anything about it.

Is there anyway for the code to know if the future was "gotten"? If there is, then you could imagine that the code does something like:

user_callback(future);
if (future.not_gotten() && future.has_exception()) {
  try {
    future.get();
  catch (std::execption & exc) {
    log_error_stream("Unhandled exception in future: " << exc);
  }
}

Another thought is that boost::asio returns the value and the exception as parameters to the callback. It's not clear to me that this a better way to structure the callback signature, but it's worth thinking about as we work on this API.

[esteve]

Is there anyway for the code to know if the future was "gotten"? If there is, then you could imagine that the code does something like:

I don't think there is, but I could be wrong.

Another thought is that boost::asio returns the value and the exception as parameters to the callback. It's not clear to me that this a better way to structure the callback signature, but it's worth thinking about as we work on this API.

I think that'd be a good idea.

[wjwwood]

Other than my questions about the callback taking a future, lgtm. Thanks!

[wjwwood]

All of my comments which I think should result in a change before merge have been addressed, +1.

[dirk-thomas]

Please squash before merging.