谷歌瀏覽器的原始碼分析 20

2021-09-30 20:18:35 字數 3273 閱讀 8050

由於這個瀏覽器是使用多程序的架構來工作的,所以程序之間就需要相互交流,這種交流是就是通訊,可以從原始碼裡看到它是使用ipc的機制來通訊,實際採用的技術,就是windows的命名管道的方式。可以看到這段**:

#001  bool channel::createpipe(const wstring& channel_id, mode mode) ;

#006      security_attributes.binherithandle = false;

#007      security_attributes.nlength = sizeof(security_attributes);

#008      if (!win_util::getlogonsessiononlydacl(

#009          reinterpret_cast(

#010              &security_attributes.lpsecuritydescriptor)))

#013 

#014      pipe_ = createnamedpipew(pipe_name.c_str(),

#016                                  file_flag_first_pipe_instance,

#017                               pipe_type_byte | pipe_readmode_byte,

#018                               1,         // number of pipe instances

#019                               buf_size,  // output buffer size (*** tune)

#020                               buf_size,  // input buffer size (*** tune)

#021                               5000,      // timeout in milliseconds (*** tune)

#022                               &security_attributes);

#023      localfree(security_attributes.lpsecuritydescriptor);

#024    } else

上面這段**通過windows api函式createnamedpipew函式來建立命名管道的伺服器端,而通過windows api函式createfilew來開啟客戶端,這樣兩個程序之間就建立起來通訊的管道,兩個程序之間的訊息就可以相互傳送了。

在瀏覽網頁連線的訊息,就是通過ipc的機制,讓類renderprocesshost把訊息傳送出去,那麼這個訊息是誰在另一端接收的呢?按照ipc的機制可知是另外乙個程序在接收,這個程序就是類renderprocess。

類renderprocesshost把所有的訊息通過類ipc::channelproxy傳送出去,在另乙個子程序裡通過類renderthread和類renderview來接收訊息,然後在類renderthread和類renderview把訊息分發處理。

再分享一下我老師大神的人工智慧教程吧。零基礎!通俗易懂!風趣幽默!還帶黃段子!希望你也加入到我們人工智慧的隊伍中來!

由於這個瀏覽器是使用多程序的架構來工作的,所以程序之間就需要相互交流,這種交流是就是通訊,可以從原始碼裡看到它是使用ipc的機制來通訊,實際採用的技術,就是windows的命名管道的方式。可以看到這段**:

#001  bool channel::createpipe(const wstring& channel_id, mode mode) ;

#006      security_attributes.binherithandle = false;

#007      security_attributes.nlength = sizeof(security_attributes);

#008      if (!win_util::getlogonsessiononlydacl(

#009          reinterpret_cast(

#010              &security_attributes.lpsecuritydescriptor)))

#013 

#014      pipe_ = createnamedpipew(pipe_name.c_str(),

#016                                  file_flag_first_pipe_instance,

#017                               pipe_type_byte | pipe_readmode_byte,

#018                               1,         // number of pipe instances

#019                               buf_size,  // output buffer size (*** tune)

#020                               buf_size,  // input buffer size (*** tune)

#021                               5000,      // timeout in milliseconds (*** tune)

#022                               &security_attributes);

#023      localfree(security_attributes.lpsecuritydescriptor);

#024    } else

上面這段**通過windows api函式createnamedpipew函式來建立命名管道的伺服器端,而通過windows api函式createfilew來開啟客戶端,這樣兩個程序之間就建立起來通訊的管道,兩個程序之間的訊息就可以相互傳送了。

在瀏覽網頁連線的訊息,就是通過ipc的機制,讓類renderprocesshost把訊息傳送出去,那麼這個訊息是誰在另一端接收的呢?按照ipc的機制可知是另外乙個程序在接收,這個程序就是類renderprocess。

類renderprocesshost把所有的訊息通過類ipc::channelproxy傳送出去,在另乙個子程序裡通過類renderthread和類renderview來接收訊息,然後在類renderthread和類renderview把訊息分發處理。

谷歌瀏覽器的原始碼分析 20

由於這個瀏覽器是使用多程序的架構來工作的,所以程序之間就需要相互交流,這種交流是就是通訊,可以從原始碼裡看到它是使用ipc的機制來通訊,實際採用的技術,就是windows的命名管道的方式。可以看到這段 001 bool channel createpipe const wstring channel...

谷歌瀏覽器的原始碼分析 8

上一次說到處理wm char訊息,當使用者每鍵入乙個字元時,萬能連線框就會去進行一次查詢的過程,然後把智慧型提示資訊顯示出來。說到autocompleteedit handlekeystroke函式的操作,那麼它為什麼需要凍結這個函式的使用呢?現在就來分析這部份的內容。如下 scopedfreeze...

谷歌瀏覽器的原始碼分析 30

上次說到函式winhttpreaddata 通過上面的函式可以看到,當資料接收完成後,就會呼叫docallback函式處理接收到的資料。docallback函式的 如下 看到這裡又是乙個 函式c run的通知,它是呼叫開始建立這個連線時設定的 物件。如果是http請求,那麼這個請求 函式是物件url...