unimrcp源码窥探及task异步架构的学习(一)（Framework Agent）

 

设置日志DEBUG级别，对照日志从main函数进入处理流程。必要时候用gdb工具单步执行调试。

 

一、task分析

了解task 的一切，从task创建开始。先来了解一下，apt_task_t这个结构体中包含了哪些数据。

• 父task链表节点(注释的说法是这样的)  link

说明，环(ring)是一种双向链表，可以在不知道其头部在哪里的情况下进行操作。APR中的环的介绍，请看另外一篇文章的详解。

定义如下：      

     APR_RING_ENTRY(apt_task_t) link;                 /* entry to parent task ring */

 

 APR_RING_ENTRY是一个宏定义，按照宏定义展开的话，以上的定义是这样的结构：

struct {                               \

   struct apt_task_t * volatile next;  \

   struct apt_task_t * volatile prev;  \

}link;

 

由此可见，link为我们记录了访问父task链表的入口节点。

 

• 子task的链表头(按照注释的理解) head

    APR_RING_HEAD(apt_task_head_t, apt_task_t) head; /* head of child tasks ring */

我们把APR_RING_HEAD的宏定义展开，得到实际的结构：

struct apt_task_head_t {                            \

    struct apt_task_t * volatile next;                    \

    struct apt_task_t * volatile prev;                    \

}head;

 

• 无类型指针 obj

obj是与任务关联的外部对象

 

 

• 消息池   msg_pool

 

• 互斥锁 data_guard

 

• 虚方法表结构 vtable

虚方法表结构中有三类函数指针：

task的方法，  start/ run/ terminate/destroy方法

消息处理的有关方法， 发信号消息处理（ signal_msg） 、消息处理( process_msg)、消息处理启动（ process_start）、消息处理终止( process_terminate)

事件处理的有关方法， pre_run / post_run/  on_ start_complete / on_ terminate_complete/ on_offline_complete / on_online_complete  

 

红色标注的三个方法，在 apt_task_create函数中分别进行了赋值，由此可见他们是所有task通用的方法，没有自定义：

    task->vtable. terminate= apt_task_terminate_request;

    task->vtable. process_start= apt_task_start_process_internal;

    task->vtable. process_terminate= apt_task_terminate_process_internal;

 

二、task实体

那么分析完apt_task_t以后，我们来解剖一下umc客户端，看看运行这样一个程序需要启动的task实体类型。

 

1. Framework Agent

 配置类型？  对应的是UmcFramework的实例

最外层这个大的Agent，定义了UmcFramework这个类来进行管理。

重点关注m_pTask(apt_consumer_task_t*)变量 、m_pMrcpClient(mrcp_client_t*)变量和m_pMrcpApplication变量(mrcp_application_t*)

下面对此进行分解。首先是拿m_pTask来讲一下。

①创建task  对应的函数是UmcFramework::CreateTask()

先调用apt_consumer_task_create去创建一个consumer_task结构，在这创建的过程中，首先就要创建apt_task_t的结构，并将apt_task_t作为成员变量(base)存放于apt_consumer_task_t结构中。

 

②虚方法表中的 run方法、 signal_msg方法，在此处被定义赋值，既然是使用的 consumer，自然run方法和 singal_msg方法是跟consumer强关联的：

static apt_bool_t apt_consumer_task_msg_signal(apt_task_t *task, apt_task_msg_t *msg);

static apt_bool_t apt_consumer_task_run(apt_task_t *task);

这儿两个函数指针实例化，体现的正好是生产者/消费者模型。注意，不要跟apt_consumer_task_t的概念弄混淆。

 

signal后缀的函数，干一个事情，就是将一个apt_task_msg_t类型的消息，压入到消息队列中（生产）。

run后缀的函数，里面是一个无线循环，从消息队列中取消息，然后进行处理(消费)。具体实现上，要区分消息类型，根据消息种类不同(TASK_MSG_CORE/ TASK_MSG_USER)，交给不同的函数去处理：

TASK_MSG_CORE类型的消息，是通过apt_task_msg_process去调用apt_core_task_msg_process函数进行处理

TASK_MSG_USER类型的消息，是通过apt_task_msg_process去调用process_msg这个函数指针，目前执行到这儿这个函数指针还没有实例化，是一个空指针。

 

处理完上述内容以后，回到CreateTask函数继续， 接下来拿到虚方法表结构，在这里先给 process_msg方法赋值，也就是上述生产者/消费者模型中，真正要处理TASK_MSG_USER消息的地方。

再把两个事件处理方法进行实现，就是 on_ start_complete方法和 on_ terminate_complete方法。

on_ start_complete方法会在 process_start执行的时候被调用到，

 

③最后一步，执行apt_task_start()函数，启动这个task！

默认是会再启一个线程执行启动操作的。线程中按照时间轴处理，流程是这样：

 

触发on_pre_run事件（当前该task没有定义该事件的触发）

 

             ↓

 

    修改task状态机

 

             ↓

 

process_start处理    

• 实际执行apt_task_start_process_internal函数
• 从子任务队列中取出任务并执行(如果有)
• 触发 on_ start_complete事件(没有子任务的情况下)

                                 

             ↓

 

      执行task

• 虚方法表例的run方法，已用apt_consumer_task_run赋值
• 无线循环，从消息池中取消息并消费消息

 

             ↓

 

task退出运行，修改task状态机

 

             ↓

 

触发on_post_run事件

 

 

 

Done！这样Framework Agent跑起来了！

写在最后：

 on_ start_complete事件中，完成了sip协议栈、mrcp协议栈的工作线程的创建和启动。详细可以见(二)中的解析。