Mojo: request/response bindings

Mojo: request/response C++ bindings

Introduces mojo::Callback<Sig> in the generated C++ bindings, which is used to handle asynchronous responses. base::Callback<Sig> can be adapted to mojo::Callback<Sig>, allowing for convenient use in Chromium. mojo::Callback<Sig> also defines an inner type named Runnable that can be subclassed and passed to the mojo::Callback<Sig> on construction. This is a lower-level way of initializing a mojo::Callback<Sig>. (pump.py from gtest/scripts is likewise used to generate mojo::Callback<Sig>.)

In the C++ bindings, two new class types are introduced: {{class_name}}_{{method.name}}_ForwardToCallback and {{class_name}}_{{method.name}}_ProxyToResponder. *ForwardToCallback is a MessageReceiver that lives on the client side to deserialize a response Message and invoke a callback. *ProxyToResponder lives on the server side and is a Callback<Sig>::Runnable that serializes the response parameters to a Message and forwards them to a MessageReceiver (responder).

In other words, the response flow starts with parameters passed to a Callback bound to a *ProxyToResponder instance, which serializes those parameters, and passes the message to the Router's MessageReceiver. This Message then appears on the client-side, and is passed to *ForwardToCallback, which was set on the client-side's Router. That *ForwardToCallback instance deserializes the message and forwards the parameters on to the client's mojo::Callback<Sig> instance.

Existing jinja2 templates for proxies and stubs were refactored so that parts of them could be shared with the implementations of *ForwardToCallback and *ProxyToResponder.

In addition to {{class_name}}_{{method.name}}_Params_Data, we now also have {{class_name}}_{{method.name}}_ResponseParams_Data when appropriate.

Suppression of clang's -Wunused-private-field was broadened to include all of module.cc.tmpl since empty interfaces can end up with unused member variables. This seemed better than trying to avoid the member variables.

public/bindings/lib/callback_internal.h resembles base/callback_internal.h a little bit. It was necessary to use unique names for some of these types though as otherwise we'd end up with conflicts when code in mojo/ uses base::Callback since it might see two classes named "internal::CallbackParamTraits", etc. This was a bit unfortunate. I inserted "_" in the mojo::internal:: names (e.g., Callback_ParamTraits) to deal with this issue.

Also, unlike base::internal::CallbackParamTraits, it was necessary for mojo::internal::Callback_ParamTraits::ForwardType to be a non-reference type for primitives (e.g., int32_t). This way the signature of Callback<Sig>::Runnable::Run(...) would match the signature of our generated C++ bindings. This was a bit subtle to get right, but thanks to some template specialization based on mojo::internal::TypeTraits<T>::kIsObject, it all seems to work.

Modify view_manager.mojom and command_buffer.mojom to take advantage of callbacks.

R=viettrungluu@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257462

[darin (slow to review), 2014-03-15 23:52:52]

Sorry for not breaking this up into smaller patches. There's a lot going on in
this one.

[viettrungluu, 2014-03-17 17:02:44]

LGTM. Are you also going to update the JS generator?

[darin (slow to review), 2014-03-17 17:15:46]

The CQ bit was checked by darin@chromium.org

[darin (slow to review), 2014-03-17 17:15:51]

The CQ bit was unchecked by darin@chromium.org

[darin (slow to review), 2014-03-17 17:44:07]

Committed patchset #15 manually as r257462 (presubmit successful).