Wayland (三) Wayland中的跨进程过程调用浅析 [FW]

首先Server端的Compositor在启动时会在$XDG_RUNTIME_DIR文件夹下创建用于监听的socket，默觉得wayland-0。然后把该socket fd增加event loop等待的fd列表。參考实现位于weston_create_listening_socket() -> wl_display_add_socket_auto() -> _wl_display_add_socket()。当有Client连接时，回调处理函数为socket_data()，当中会调用wl_os_accept_cloexec()得到与该Client相连的socket fd。然后调用wl_client_create()，创建wl_client。Server端会为每个连接的Client创建wl_client，这些对象被串在display->client_list这个列表里。wl_client中的wl_connection代表这个与Client的连接，当中包括了in buffer和out buffer，分别作为输入和输出的缓冲区。注意这个in buffer和out buffer都是双份的，一份for普通数据，一份for fd，由于fd须要以out-of-band形式传输，要特殊处理。wl_event_loop_add_fd()会把这个与Client连接的socket fd增加到event loop等待的列表中，回调处理函数为wl_client_connection_data()。

    wl_display_add_socket_auto()

        wl_socket_init_for_display_name() // $XDG_RUNTIME_DIR/wayland-0,

        _wl_display_add_socket() 

            wl_os_socket_cloexec() // create socket

            bind() 

            listen() 

            wl_event_loop_add_fd(.., socket_data,...) // 创建wl_event_source_fd，它代表一个基于socket fd的事件源。处理函数是wl_event_source_fd_dispatch()，当中会调用这里參数里的回调函数socket_data()。

                add_source() // 把刚创建的监听socket fd，通过epoll_ctl()附加到loop->epoll_fd上。这样消息循环就能够在上面等待Client的连接了。

 

当有Client连接到Server的监听socket上，会调用刚才注冊的回调函数socket_data()，然后会调用wl_os_accept_cloexec()->accept()创建与Client连接的fd。接着调用wl_client_create()创建Client对象。

    wl_os_accept_cloexec()

    wl_client_create()

        client->connection = wl_connection_create() 

        wl_map_init(&client->objects) // 初始化wl_map对象，用于映射Server和Client端的对象。

        bind_display() // 绑定Client端的wl_display代理对象与Server端的display资源对象。

            client->display_resource = wl_resource_create(.., &wl_display_interface,...) // display资源对象的接口就是wl_display_interface，request的实如今display_interface中。这里创建wl_resource结构，当中resource->object是一个可供Client调用的远端对象的抽象，当中的成员interface和implementation分别代表其接口和实现。然后用wl_map_insert_at()插入到client->objects的wl_map结构中供以后查询。

            wl_resource_set_implementation(..., &display_interface, ...)  // 对Client而言，Server端提供的接口实现是request部分。

 

Client端要连接Server端，是通过调用wl_display_connect()。当中会创建socket而且调用connect()连接Server端创建的监听port。得到与Server端连接的socket fd后调用wl_display_connect_to_fd()创建wl_display。wl_display是Server端的display资源在Client端的代理对象，它的第一个元素wl_proxy，因此它能够与wl_proxy互转。和Server端一样，也会创建一个wl_connection包括读写缓冲区。

 

在Server端，Compositor初始化完后会调用wl_display_run()进入大循环。这个函数主体是：

while (...) {

    wl_display_flush_clients() // 将相应的out buffer通过socket发出去。

    wl_event_loop_dispatch() // 处理消息循环。

}

wl_event_loop代表主消息循环，wl_event_loop_dispatch()的大多数时间会通过epoll_wait()等待在wl_event_loop的epoll_fd上。epoll是类似于select, poll的机制，能够让调用者等待在一坨fd上，直到当中有fd可读、可写或错误。这个event loop和当中的epoll_fd是Compositor在wl_display_create() ->  wl_event_loop_create()时创建的。

 

wl_event_source代表wl_event_loop中等待的事件源。它有多种类型，比方wl_event_source_fd, wl_event_source_timer和wl_event_source_signal。它们分别代表由socket fd, timerfd和signalfd触发的事件源。wl_event_source_idle比較特殊，当消息循环处理完那些epoll_fd上等到的事件后，在下一次堵塞在epoll_wait()上前，会先处理这个idle list里的事件。比方有Client更新graphic buffer后会调用weston_output_schedule_repaint() -> wl_event_loop_add_idle()，就是往这个idle list里加一个消息。wl_event_source_fd的创建为例，在Client连接到Server时，Server会调用wl_client_create() -> wl_event_loop_add_fd()->add_source()将之增加到display的loop上，其处理回调函数为wl_client_connection_data()，意味着当主消息循环在这个Client相应的socket上读到数据时，就会调用wl_client_connection_data()进行处理。

 

在Client端，当须要与Server端交换数据时，终于会调用wl_display_dispatch_queue()。当中最基本的是三件事：

1. wl_connection_flush()将当前out buffer中的数据通过socket发往Server端。这些数据是之前在wl_connection_write()中写入的。

2. 通过poll()在socket上等待数据，并通过read_events()将这些数据处理生成函数闭包结构wl_closure，然后放到display的wl_event_queue.event_list事件列表中。wl_closure能够看作是一个函数调用实例，里面包括了一个函数调用须要的全部信息。

3. dispatch_queue()->dispatch_event()用于处理前面加入到队列的事件。这里就是把队列中的wl_closure拿出来生成trampoline后进行调用。

 

 

术语上，Wayland中把Client发给Server的跨进程函数调用称为request，反方向的跨进程函数调用称为event。本质上，它们处理的方式是类似的。要让两个进程通过socket进行函数调用，首先须要将调用抽象成数据流的形式。函数的接口部分是同一时候链接到Client和Server端的库中的，当中包括了对象所支持的request和event的函数签名。因此这部分不用传输，仅仅要传输目标对象id，方法id和參数列表这些信息就能够了。这些信息会通过wl_closure_marshal()写入wl_closure结构，再由serialize_closure()变成数据流。等到了目标进程后，会从数据流通过wl_connection_demarshal()转回wl_closure。这个过程类似于Android中的Parcel机制。那么问题来了，參数中的整形，字符串什么的都好搞，拷贝即可。但假设參数中包括对象，我们不能把整个对象拷贝过去，也不能传引用过去。那么须要一种机制来作同一对象在Server和Client端的映射，这是通过wl_map实现的。wl_map在Client和Server端各有一个，它们分别存了wl_proxy和wl_resource的数组，且是一一相应的。这些对象在这个数组中的索引作为它们的id。这样，參数中的对象仅仅要传id，这个id被传到目的地后会通过查找这个wl_map表来得到本地相应的对象。在功能上类似于Android中的BpXXX和BnXXX。wl_proxy和wl_resource都包括wl_object对象。这个wl_object和面向对象语言里的对象概念类似，它有interface成员描写叙述了这个对象所实现的接口，implementation是这些接口的实现函数的函数指针数组，id就是在wl_map结构里数组中的索引。前面所说的Client绑定Server端资源的过程就是在Client端创建wl_proxy，在Server端创建wl_resource。然后Client就能够通过wl_proxy调用Server端相应wl_resource的request，Server端就能够通过wl_resource调用Client端相应wl_proxy的event。这个映射步骤例如以下图所看到的(以wl_registry为例)：

   54     <request name="get_registry">
   55       <description summary="get global registry object">
   56     This request creates a registry object that allows the client
   57     to list and bind the global objects available from the
   58     compositor.
   59       </description>
   60       <arg name="registry" type="new_id" interface="wl_registry"/>
   61     </request>  147 static const struct wl_message wl_display_requests[] = {
 148     { "sync", "n", types + 8 },
 149     { "get_registry", "n", types + 9 },
 150 };
 151 
 152 static const struct wl_message wl_display_events[] = {
 153     { "error", "ous", types + 0 },
 154     { "delete_id", "u", types + 0 },
 155 };
 156 
 157 WL_EXPORT const struct wl_interface wl_display_interface = {
 158     "wl_display", 1,
 159     2, wl_display_requests,
 160     2, wl_display_events,
 161 };   143     void (*get_registry)(struct wl_client *client,
  144                  struct wl_resource *resource,
  145                  uint32_t registry);   184 static inline struct wl_registry *
  185 wl_display_get_registry(struct wl_display *wl_display)
  186 {
  187     struct wl_proxy *registry; 
  188 
  189     registry = wl_proxy_marshal_constructor((struct wl_proxy *) wl_display,
  190              WL_DISPLAY_GET_REGISTRY, &wl_registry_interface, NULL);
  191 
  192     return (struct wl_registry *) registry;
  193 }