Chrome源代码分析之single process 模式分析(十七)
2013-06-08 15:17
543 查看
如果选择了单进程模式,那么只需要建立一个renderer线程即可,同时为这个线程搭建ipc功能,虽然同一个进程,renderer与browser之间仍然通过ipc通信,这样多进程和单进程的通信方法统一在一起了。各种IPC消息的映射代码不需要做任何改动。
代码如下:
// Crank up a thread and run the initialization there. With the way that
// messages flow between the browser and renderer, this thread is required
// to prevent a deadlock in single-process mode. Since the primordial
// thread in the renderer process runs the WebKit code and can sometimes
// make blocking calls to the UI thread (i.e. this thread), they need to run
// on separate threads.
in_process_renderer_.reset(new RendererMainThread(channel_id));
base::Thread::Options options;
#if !defined(TOOLKIT_USES_GTK)
// In-process plugins require this to be a UI message loop.
options.message_loop_type = MessageLoop::TYPE_UI;
#else
// We can't have multiple UI loops on GTK, so we don't support
// in-process plugins.
options.message_loop_type = MessageLoop::TYPE_DEFAULT;
#endif
in_process_renderer_->StartWithOptions(options);
OnProcessLaunched(); // Fake a callback that the process is ready.
这里定义个了一个in_process_renderer_代表整个render,RendererMainThread是Thread的子类,RendererMainThread中也有一个RenderProcessImpl类的对象,RenderProcessImpl跟多进程模式下一样有一个main_thread_和io_thread_对象,main_thread_就是前面定义的RendererMainThread线程,后面即会调用n_process_renderer_->StartWithOptions(options);启动这个线程。
RendererMainThread的nit()函数代码如下:
virtual void Init() {
#if defined(OS_WIN)
CoInitialize(NULL);
#endif
render_process_ = new RenderProcessImpl();
render_process_->set_main_thread(new RenderThread(channel_id_));
// It's a little lame to manually set this flag. But the single process
// RendererThread will receive the WM_QUIT. We don't need to assert on
// this thread, so just force the flag manually.
// If we want to avoid this, we could create the InProcRendererThread
// directly with _beginthreadex() rather than using the Thread class.
base::Thread::SetThreadWasQuitProperly(true);
}
virtual void CleanUp() {
delete render_process_;
#if defined(OS_WIN)
CoUninitialize();
#endif
}
这里面会新建RenderProcessImpl的对象,如同多进程模式一样,ipc对象和io线程随后会在RenderThread和RenderProcessImpl的构造函数中被创建和初始化。
代码如下:
// Crank up a thread and run the initialization there. With the way that
// messages flow between the browser and renderer, this thread is required
// to prevent a deadlock in single-process mode. Since the primordial
// thread in the renderer process runs the WebKit code and can sometimes
// make blocking calls to the UI thread (i.e. this thread), they need to run
// on separate threads.
in_process_renderer_.reset(new RendererMainThread(channel_id));
base::Thread::Options options;
#if !defined(TOOLKIT_USES_GTK)
// In-process plugins require this to be a UI message loop.
options.message_loop_type = MessageLoop::TYPE_UI;
#else
// We can't have multiple UI loops on GTK, so we don't support
// in-process plugins.
options.message_loop_type = MessageLoop::TYPE_DEFAULT;
#endif
in_process_renderer_->StartWithOptions(options);
OnProcessLaunched(); // Fake a callback that the process is ready.
这里定义个了一个in_process_renderer_代表整个render,RendererMainThread是Thread的子类,RendererMainThread中也有一个RenderProcessImpl类的对象,RenderProcessImpl跟多进程模式下一样有一个main_thread_和io_thread_对象,main_thread_就是前面定义的RendererMainThread线程,后面即会调用n_process_renderer_->StartWithOptions(options);启动这个线程。
RendererMainThread的nit()函数代码如下:
virtual void Init() {
#if defined(OS_WIN)
CoInitialize(NULL);
#endif
render_process_ = new RenderProcessImpl();
render_process_->set_main_thread(new RenderThread(channel_id_));
// It's a little lame to manually set this flag. But the single process
// RendererThread will receive the WM_QUIT. We don't need to assert on
// this thread, so just force the flag manually.
// If we want to avoid this, we could create the InProcRendererThread
// directly with _beginthreadex() rather than using the Thread class.
base::Thread::SetThreadWasQuitProperly(true);
}
virtual void CleanUp() {
delete render_process_;
#if defined(OS_WIN)
CoUninitialize();
#endif
}
这里面会新建RenderProcessImpl的对象,如同多进程模式一样,ipc对象和io线程随后会在RenderThread和RenderProcessImpl的构造函数中被创建和初始化。
相关文章推荐
- Chrome源代码分析之运行模式(十四)
- Chrome源代码分析之Renderer进程初始化(十五)
- Chrome源代码分析之IPC(九)
- Mozilla Firefox Extension扩展 内幕 教程 源代码分析 安装过程分析(XPInstall,xpcom,rdf,xpi,chrome,manifest)
- 重构桌面飘着圣诞老人,利用策略模式和改造的代理模式让软件完全实现开闭原则,欢迎下载源代码分析
- Chrome源代码分析之socket(一)
- Chrome源代码分析之线程模型(十一)
- Android多任务切换与Activity启动模式SingleTask之间关系的分析
- Mozilla Firefox Extension扩展 内幕 教程 源代码分析 安装过程分析(XPInstall,xpcom,rdf,xpi,chrome,manifest)
- u-boot-2012.10 shell模式命令自动补齐功能 源代码分析
- Chrome源代码分析之Renderer进程初始化(十五)
- Chrome源代码分析之IPC续(十)
- BlogEngine.Net架构与源代码分析系列part3:数据存储——基于Provider模式的实现
- Chrome源代码分析之socket(六)
- BlogEngine.Net架构与源代码分析系列part3:数据存储——基于Provider模式的实现
- Chrome源代码分析之Renderer进程初始化续(十六)
- Chrome源代码分析之初始化(七)
- 今天看到的关于activity四种启动模式分析的文章(standard、singleTop、singleTask、singleInstance)
- BlogEngine.Net架构与源代码分析系列part3:数据存储——基于Provider模式的实现
- Chrome源代码分析之进程和线程模型(三)