communication between render, io, browser threads

[sangeeta chowdhary]

Hi Guys,

I have been analyzing communication between various threads in chrome browser. I have been using Kitkat device, with default browser.
I have seen Browser thread communicating with IO thread with message loops. Here is the backtrace

But, Browser thread and Renderer thread is communicating with IPC, although they belong to same process, then what is the need of using IPC(channel proxy) between these two threads.

Regards,
Sangeeta

[Torne (Richard Coles)]

On 6 June 2014 07:00, sangeeta chowdhary <sangitac...@gmail.com> wrote:

Hi Guys,

I have been analyzing communication between various threads in chrome browser. I have been using Kitkat device, with default browser.

By "default browser" you mean the AOSP browser, which is not Chrome (but does use the chromium WebView)?

 

I have seen Browser thread communicating with IO thread with message loops. Here is the backtrace

But, Browser thread and Renderer thread is communicating with IPC, although they belong to same process, then what is the need of using IPC(channel proxy) between these two threads.

The WebView runs in single process mode for technical reasons, but this is the only case where single process mode is used in production. All other builds of Chromium use separate processes for the browser and renderer. They communicate using an IPC primitive because nobody wants to do a bunch of work to make it work differently in the WebView; this would have few benefits and introduce the possibility of weird bugs that only reproduce on this platform.

[sangeeta chowdhary]

Hi Torne,

Default browser in Nexus 5, I think its stock browser, but it uses libwebviewchromium.so library.

You said "but this is the only case where single process mode is used in production"

What is this only reason?

And why for this browser there are not different processes?

For Chrome there would be different process for render,browser,io?

If so, in your document on threading - http://www.chromium.org/developers/design-documents/threading

they have been mentioned as threads.

Another question is, if they are running as threads, means having same address space, then what is the need of channel proxy. If you want to use channel proxy for some reasons, then why browser process and io thread communicates with message loops?

[Torne (Richard Coles)]

On 6 June 2014 10:42, sangeeta chowdhary <sangitac...@gmail.com> wrote:

Hi Torne,

Default browser in Nexus 5, I think its stock browser, but it uses libwebviewchromium.so library.

The default browser in official Nexus 5 images is Chrome, not the "old" Android browser, so presumably you're talking about AOSP :)

 

You said "but this is the only case where single process mode is used in production"

What is this only reason?

We use multiprocess mode where we can, which is everywhere except the Android WebView.

 

And why for this browser there are not different processes?

The way the WebView integrates into an existing app that only has one process makes it very difficult to create more processes to use for renderers.

 

For Chrome there would be different process for render,browser,io?

No, just for the renderer and browser.

 

If so, in your document on threading - http://www.chromium.org/developers/design-documents/threading

they have been mentioned as threads.

There are a *lot* of threads in chrome. Some of them normally exist in the browser process, some of them normally exist in the renderer process. In single-process mode on the WebView the threads all exist in the same process.

 

Another question is, if they are running as threads, means having same address space, then what is the need of channel proxy. If you want to use channel proxy for some reasons, then why browser process and io thread communicates with message loops?

The channel proxy is needed because in *every other configuration*, the browser and renderer aren't running in the same process, so they must use IPC to communicate with each other. As I said in my last mail, they don't *need* to use IPC in the single-process WebView, but they still do, because it's easier than having a special case in the code.

The main browser thread and the IO thread communicate directly because they always both live in the browser process.