7 实际使用WebRTC的线程模型
在这一章节我将实际演示如何将WebRTC的/trunk/talk/base目录下的所有文件编译成静态库。并且在这基础上编译运行2个小程序,以观察整个线程模型的调用关系。这将能够很好地帮助读者理解各个模块是如何协同工作的。
7.1 编译静态库
正如在本文开头时提到的,这一节的内容可能是大家最感兴趣的,但也是我不得不和大家说声抱歉的,我是在Mac OSX平台上完成了对WebRTC的/trunk/talk/base目录下的源代码的编译。所以编译脚本只能在Mac OSX下使用,不过我相信向Linux和Windows移植的工作应该不会很困难。因为:
1 WebRTC本身就是跨平台编写的,它本身就支持所有的平台;
2 谷歌已经为WebRTC编写了完美的编译脚本,这种脚本以Python为基础可以在各个平台上使用命令行编译或者生成IDE(包括Visual Studio)工程脚本。特别要提一下的是谷歌使用的ninjia实在太强大了,编译速度超快无比,推荐使用;
3 我所使用的脚本并不复杂,所以通过简单修改应该可以在各个平台上使用;
基于以上的原因,可能大家会觉得我自己写编译脚本有些多此一举。从理论上来说确实有些多此一举,但是我也有我自己的理由:
1 最近为了找工作所以学习了一些关于make脚本的知识,这次正好用来练手。其实在以前的工作中使用过nmake,不过主体框架是美国同事写得,我们不过是在添加删除文件时维护一下。所以,这次学习WebRTC源代码可以有机会在实践中检验一下对make脚本的理解。
2 我希望将/trunk/talk/base目录独立编译出来,这样可以将它作为独立的模块进行试验,避免被其他模块干扰。
言归正题,让我们先来看一下编译脚本:
- .PHONY = all create_dir clean
-
- CC := g++
- COCOACC := g++
- AR := ar
-
- ut_srcs := $(wildcard *_unittest.cc)
- exclusive_files := $(ut_srcs) \
- diskcache_win32.ccjson.cc linuxwindowpicker.cc \
- macsocketserver.ccnatserver_main.cc schanneladapter.cc \
- sslidentity.ccunittest_main.cc win32.cc win32filesystem.cc \
- win32regkey.ccwin32securityerrors.cc win32socketserver.cc \
- win32window.ccwin32windowpicker.cc winfirewall.cc winping.cc
-
- proj_dir := ../..
- obj_dir := $(proj_dir)/bin/talk_base
-
- all_srcs := $(wildcard *.cc)
- srcs := $(filter-out $(exclusive_files),$(all_srcs))
-
- objs := $(patsubst %.cc, %.o, $(srcs))
- fp_objs := $(addprefix $(obj_dir)/,$(objs))
-
- cocoa_srcs := scoped_autorelease_pool.mm maccocoathreadhelper.mm
- cocoa_objs := $(patsubst %.mm, %.o,$(cocoa_srcs))
- fp_cocoa_objs := $(addprefix $(obj_dir)/,$(cocoa_objs))
-
- CCFLAGS := -DPOSIX -DOSX -I$(proj_dir) -g
- COCOACCFLAGS := -DOSX -I$(proj_dir) -g
- ARFlAGS := crv
-
- all: create_dir $(fp_objs) $(fp_cocoa_objs)
- $(AR)$(ARFlAGS) $(obj_dir)/libtalkbase.a $(fp_objs) $(fp_cocoa_objs)
-
- $(fp_objs): $(obj_dir)/%.o: %.cc
- $(CC)$(CCFLAGS) -o $@ -c $^
-
- $(fp_cocoa_objs): $(obj_dir)/%.o: %.mm
- $(COCOACC)$(COCOACCFLAGS) -o $@ -c $^
-
- create_dir:
- mkdir-p $(obj_dir)
-
- clean:
- rm-rf $(obj_dir)
对于使用惯Visual Studio的Windows开发人员来说,make脚本确实有些晦涩,不过以上脚本并不是很难。由于初次编写make脚本,所以特意避开了一些复杂的技巧,并且尽可能不考虑编译环境的通用性。比如,通常make脚本需要生成依赖文件(*.d),由于当前只是为了编译确定版本的WebRTC代码(代码不会发生变化),所以我省略了这一步。
整个make脚本的大致就是先把所有的代码文件(*.cc)罗列出来,然后去除掉unit test文件,以及一些Windows平台下特有的文件。将余下的文件使用g++编译成目标文件(*.o)。由于我使用的是Mac OSX平台,所以需要特别编译几个Mac OSX的代码文件(*.mm)文件。最后使用ar工具将所有的目标文件(*.o)打包成静态库(libtalkbase.a)。整个过程并没有什么特别的。不过,由于初次编写make脚本,有些地方并不是很规范(比如变量名的使用),请各位读者见谅。
7.2 范例代码1
这里先让我们看一段网上摘录的代码:
- #include <string>
- #include <iostream>
- #include "talk/base/thread.h"
-
- class HelpData : publictalk_base::MessageData
- {
- public:
- std::string info_;
- };
-
- class Police : publictalk_base::MessageHandler
- {
- public:
- enum {
- MSG_HELP,
- };
-
- void Help(const std::string& info) {
- HelpData* data = new HelpData;
- data->info_ = info;
- talk_base::Thread::Current()->Post(this, MSG_HELP, data);
- }
-
- virtual void OnMessage(talk_base::Message* msg) {
- switch (msg->message_id) {
- case MSG_HELP:
- HelpData* data = (HelpData*)msg->pdata;
- std::cout << "MSG_HELP : " << data->info_<< std::endl;
- break;
- }
- }
- };
-
- int main(int argc, char** argv)
- {
- std::cout << "Test Thread is started"<< std::endl;
- Police p;
- p.Help("Please help me!");
- talk_base::Thread::Current()->Run();
- std::cout << "Test Thread is completed"<<std::endl;
- return 0;
- }
这段代码很简单,它演示了单线程环境下如何使用消息处理器。不过这个程序会永久等待在以下语句:
talk_base::Thread::Current()->Run();
不能,正常退出。如果读者感兴趣,可以尝试以下如何使用一条延迟消息,让程序正常退出。
接下来,让我们看一下整个WebRTC代码的调用栈展开会是一个生个状况。可能会出乎你的意料,整个调用栈还是比较复杂的:
从上图可以看到,在调用talk_base::Thread::Current函数之后,整个调用栈涉及到了talk_base::ThreadManager、talk_base::MessageQueue、talk_base::MessageQueueManager三个类,其中talk_base::ThreadManager和talk_base::MessageQueueManager是在其Instance函数被调用后触发构造的全局唯一的对象实例。从这个调用栈可以看出,一旦调用有些talk_base::Thread的成员函数(静态/非静态)就会自动触发构造talk_base::ThreadManager和talk_base::MessageQueueManager,并且把当前线程封装成一个talk_base::Thread实例。
7.3 范例代码2
范例代码1是一个单线程的例子,所以并不能够足以研究WebRTC在多线程环境下的工作情况。因此,在这个例子的基础上,我把它改良成了多线程的版本:
- #include <string>
- #include <iostream>
- #include "talk/base/thread.h"
-
- class HelpData : publictalk_base::MessageData
- {
- public:
- std::string info_;
- };
-
- class Police : publictalk_base::MessageHandler
- {
- public:
- enum {
- MSG_HELP,
- };
-
- void Help(talk_base::Thread& targetThread, const std::string&info) {
- HelpData* data = new HelpData;
- data->info_ = info;
- targetThread.Post(this, MSG_HELP, data);
- }
-
- virtual void OnMessage(talk_base::Message* msg) {
- switch (msg->message_id) {
- case MSG_HELP:
- HelpData* data = (HelpData*)msg->pdata;
- std::cout << "MSG_HELP :" << data->info_<< std::endl;
- break;
- }
- }
- };
-
- int main(int argc, char** argv)
- {
- std::cout << "Test Multi-thread is started"<<std::endl;
- Police p;
- talk_base::Thread thread;
- thread.Start();
-
- p.Help(thread, "Please help me!");
- talk_base::Thread::Current()->SleepMs(100);
- std::cout << "Test Multi-thread is completed" <<std::endl;
-
- return 0;
- }
这个版本的代码仅仅就是稍微改装了一点点,但是整个调用栈的情况发生了很大的变化:
从上图可以看出,虽然在多线程环境下情况复杂得多,但是WebRTC依然可以保证talk_base::ThreadManager和talk_base::MessageQueueManager这两个全局设施可以在任何子线程启动之前被构造完毕。
结合以上2个例子,加上本文对涉及的各个类的解说,我想应该大多数读者能够掌握WebRTC的线程模型的所有细节。如果还有什么疑问的话,那就只能靠动手才能解决问题了。请将以上两个例子编译通过并在你有疑惑的函数中设置log输出,甚至于单步调试你有疑惑的代码,是掌握代码原理的终极手段。
所有评论(0)