Chrome网络部分源代码分析
namelcx
这个作者很懒,什么都没留下…
展开
-
Chrome源代码分析之进程和线程模型(三)
关于Chrome的线程模型,在他的开发文档中有专门的介绍,原文地址在这里:http://dev.chromium.org/developers/design-documents/threadingchrome的进程,chrome没有采用一般应用程序的单进程多线程的模型,而是采用了多进程的模型,按照他的文字说明,主界面框架下的一个TAB就对应这个一个进程。但实际上,一个进程不仅仅包含一个原创 2011-07-04 09:25:58 · 3535 阅读 · 0 评论 -
Chrome源代码分析之socket(二)
从这个函数可以看出Chrome采用WSAEventSelect来同服务器端建立连接,虽然WSAEventSelect的在吞吐量和处理多连接的性能这2方面无法与重叠I/O和完成度端口相提并论,但是用在客户端上足矣,而且WSAEventSelect不象WSASyncSelect那样需要与窗口句柄相关联,还能减小网络部分的耦合度,应该说是个不错的选择,不过WSAEventSelect仅仅用于TCP的连接原创 2011-07-01 13:44:00 · 2971 阅读 · 0 评论 -
Chrome源代码分析之进程和线程模型(四)
原创 2011-07-05 16:23:13 · 1528 阅读 · 0 评论 -
Chrome源代码分析之socket(五)
接着前面分析,通过对Chrome线程模型的分析以及对ObjectWatcher的初步了解,可以知道,ObjectWatcher通用在Chrome的几种线程中,包括处理界面操作的线程,网络I/O的线程以及其他线程,对于网络I/O,ObjectWatcher在初始化后与某个I/O信号量绑定,然后将其自身加入到某个线程的队列里面等待线程的处理,一旦信号量变为已执行状态,线程将调用Watch的Run函数执原创 2011-12-16 17:22:11 · 1878 阅读 · 0 评论 -
Chrome源代码分析之socket(六)
在TCPClientSocketWin中有一个细节这里单独提一下,由于其Write和Read函数返回的值得有2种,I/O字节数或者错误代码,由于WINERR和WSAERR中定义的错误是整数,而Read和Write的返回值包含了错误代码和正常的I/O字节数,因此需要将系统错误代码转化为私有的为负的错误代码。这些是通过调用MapWinsockError函数来实现的。另外还需要定义私有的错误代码来替代系原创 2012-07-11 19:03:53 · 2382 阅读 · 0 评论 -
Chrome源代码分析之socket(一)
作为对HTTP连接的分析,首先跟踪一下Chrome对一个新的URL请求的处理流程。 从Chrome的实现来看,对一个URL资源的请求是放在Browser进程中来实现的,而不是由各个Render进程来实现,据说开发文档中提到这样做的三个主要优势,一是避免子进程进行网络通信,增加安全性,二是有利于Cookie等持久化资源在不同页面中的共享,否则在不同Render进程中传递Cookie比较麻烦,原创 2011-07-01 09:35:00 · 6741 阅读 · 1 评论 -
Chrome源代码分析之初始化(七)
下面看看初始化的代码整个程序的入口位于文件:src\chrome\app\chrome_exe_main_win.cc这里只有一个入口函数wWinMain,标准的win32入口,这个函数很简单,调用CommandLine::Init(0, NULL);初始化命令行的对象,然后启动沙盒服务。最后创建MainDllLoader对象,MainDllLoader对象只有一个主要原创 2012-11-29 13:23:15 · 2889 阅读 · 0 评论