Variants

Let's assume we have a mojom file such as this:
 
module example.mojom;
 
interface Foo {
  SendData(string param1, array<int32> param2);
};
 
Given the following GN mojom definition the compiler will generate two targets: example and example_blink
 
mojom("example") {
  sources = [ "example.mojom" ]
  use_new_wrapper_types = true

}
 
The target "example" will generate Chromium-style C++ bindings using STL types:
 
// example.mojom.h

class Example {
  virtual void SendArray(const std::string& param1, const std::vector<int32_t>& param2) = 0;
}

 
The target "example_blink" will generate Blink-style C++ bindings using WTF types:
 
// example.mojom-blink.h

class Example {
  virtual void SendArray(const WTF::String& param1, const WTF::Vector<int32_t>& param2) = 0;
}

 
Thanks to these separate sets of bindings no work is necessary to convert types between Blink-style code and Chromium-style code. It is handled automatically during message serialization and deserialization.
 
Converting WTF::Function to base::Callback
 
Mojo methods that return a value take an instance of base::Callback. To solve this problem use WTF::convertToBaseCallback to turn a WTF::Function into a base::Callback that accepts the same arguments. Do not try to use base::Bind directly as it doesn't understand Oilpan. For example,
 
#include "wtf/Functional.h"

void MyObject::ReverseString(const String& string)
{
  m_service->ReverseString(
      string,
      ConvertToBaseCallback(WTF::Bind(&MyObject::onStringReversed, wrapPersistent(this))));
}

 
Mojo is not traced by Oilpan so one must be careful. If an interface pointer is owned by an managed object the message pipe will be closed during lazy sweeping. This means that messages may be received after the object has become unreachable and pointers to other managed objects are possibly invalid. To avoid this all managed objects bound with WTF::bind must be either Persistent or WeakPersistent references. This is done by wrapping pointers passed to WTF::bind with either wrapPersistent() or wrapWeakPersistent(this).
 
WeakPersistent references should be used to avoid cycles whenever a callback is expected to have the same lifetime as the object. The most common example of this is the this pointer bound to the callback passed to InterfacePtr::set_connection_error_callback.
 
Persistent references should be used at any other time when the interface pointer is owned by the bound object. This is because if no other reference to the object exists it will be garbage collected before the response is received, canceling the request. Only if this behavior is desired should a WeakPersistent be used instead.
 
If response callbacks are bound with wrapPersistent() then a connection error handler that closes the message pipe should be attached to the interface pointer. Otherwise callbacks will not be destroyed when the pipe is closed and the object will leak.
 
// m_service is a member of MyObject. This code should be run as soon as m_foo is bound to a message pipe.
m_service.set_connection_error_handler(
    ConvertToBaseCallback(WTF::Bind(&MyObject::OnConnectionError,
                                    wrapWeakPersistent(this))));

void MyObject::OnConnectionError()
{
  m_service.reset();
}

 
Implementing Mojo interfaces in Blink
 
Only a mojo::Binding or mojo::BindingSet should be used when implementing a Mojo interface in an Oilpan managed object. The object must then have a pre-finalizer to close any open pipes when the object is about to be swept as lazy sweeping means that it may be invalid long before the destructor is called. This requires setup in both the object header and implementation.
 
// MyObject.h

class MyObject : public GarbageCollected
               , public example::blink::Example
{
  USING_PRE_FINALIZER(MyObject, dispose);
 public:
  MyObject();

void dispose();

// Implementation of example::blink::Example.

private:
  mojo::Binding<example::blink::Example> m_binding;
};

// MyObject.cpp

MyObject::MyObject() : m_binding(this)
{
  ThreadState::current()->registerPreFinalizer(this);
}

void MyObject::dispose()
{
  m_binding.Close();
}

Calling Mojo from Blink的更多相关文章

  1. [Chromium文档转载,第005章]Calling Mojo from Blink

    For Developers‎ > ‎Design Documents‎ > ‎Mojo‎ > ‎ Calling Mojo from Blink Variants Let's as ...

  2. Mojo C++ Bindings API

    This document is a subset of the Mojo documentation. Contents Overview Getting Started Interfaces Ba ...

  3. [Chromium文档转载,第002章]Mojo C++ Bindings API

    Mojo C++ Bindings API This document is a subset of the Mojo documentation. Contents Overview Getting ...

  4. Deno下一代Nodejs?Deno初体验

    前言 Ryan Dahl之父发布了新的项目Deno,很多IT媒体都使用了标题“下一代Nodejs”,首先我们看一下Deno的特性: 1.支持typescript (nodejs目前也支持). 2.无p ...

  5. Converting Legacy Chrome IPC To Mojo

    Converting Legacy Chrome IPC To Mojo Looking for Mojo Documentation? Contents Overview Deciding What ...

  6. [Chromium文档转载,第006章]Chrome IPC To Mojo IPC Cheat Sheet

    For Developers‎ > ‎Design Documents‎ > ‎Mojo‎ > ‎ Chrome IPC To Mojo IPC Cheat Sheet 目录 1 O ...

  7. [Chromium文档转载,第001章] Mojo Migration Guide

        For Developers‎ > ‎Design Documents‎ > ‎Mojo‎ > ‎ Mojo Migration Guide 目录 1 Summary 2 H ...

  8. Mojo C++ System API

    This document is a subset of the Mojo documentation. Contents Overview Scoped, Typed Handles Message ...

  9. Mojo Associated Interfaces

    Mojo Associated Interfaces yzshen@chromium.org 02/22/2017 Background Before associated interfaces ar ...

随机推荐

  1. Caffe_Scale层解析

    Caffe Scale层解析 前段时间做了caffe的batchnormalization层的解析,由于整体的BN层实现在Caffe是分段实现的,因此今天抽时间总结下Scale层次,也会后续两个层做合 ...

  2. LeetCode(15)3Sum

    题目如下: Python代码: def threeSum(self, nums): res = [] nums.sort() for i in xrange(len(nums)-2): if i &g ...

  3. Vue双向绑定原理(源码解析)---getter setter

       Vue双向绑定原理      大部分都知道Vue是采用的是对象的get 和set方法来实现数据的双向绑定的过程,本章将讨论他是怎么利用他实现的. vue双向绑定其实是采用的观察者模式,get和s ...

  4. 【Jim】I am back (ง •_•)ง

    其实上周就来考过一次试了,真是啥都忘了 (´ー∀ー`) 下午在写[树网的核],写了一半去吃饭,回来时发现高二机房的门被锁上了,于是他们都被堵在门口. 我就回到我的地方接着写码. 听到外面有个高二的妹子 ...

  5. HDU1420 - Prepared for New Acmer

    集训进行了将近2个礼拜,这段时间以恢复性训练为主,我一直在密切关注大家的训练情况,目前为止,对大家的表现相当满意,首先是绝大部分队员的训练积极性很高,其次,都很遵守集训纪律,最后,老队员也起到了很好的 ...

  6. S5PV210 三个Camera Interface/CAMIF/FIMC的区别

    S5PV210有三个CAMIF单元,分别为CAMIF0 CAMIF1和CAMIF2.对应着驱动中的fimc0, fimc1, fimc2.在三星datasheet和驱动代码中CAMIF和FIMC(Fu ...

  7. JS侧边栏实现

    <!DOCTYPE html> <html lang="en"> <style> </style> <head> < ...

  8. DelayQueue延时队列示例

    介绍: DelayQueue是一个无界阻塞队列,只有在延迟期满时才能从中提取元素.该队列的头部是延迟期满后保存时间最长的Delayed 元素. 使用场景: 缓存系统的设计,缓存中的对象,超过了空闲时间 ...

  9. UVA 11478 Halum

    Halum Time Limit: 3000ms Memory Limit: 131072KB This problem will be judged on UVA. Original ID: 114 ...

  10. c++变量的作用域、生存期和可见性

    局部变量 范围:在一个函数内部定义的变量,作用范围仅仅限于本函数体内. 生存期:程序运行到本函数才会给局部变量分配内存单元.函数运行完成局部变量所占的存储单元就被释放 全局变量 在函数体外部定义的变量 ...