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
Review URL: https://codereview.chromium.org/198343002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257462 0039d316-1c4b-4281-b951-d872f2087c98
CrOS-Libchrome-Original-Commit: 945b734cbe1af504df46ecb09d362bb3b4d05955
29 files changed