On Thu, Aug 27, 2009 at 11:57 AM, hap 497 <hap...@gmail.com> wrote:
>
>
> On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek <j...@chromium.org>wrote:
>
>>
>>
>> On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson <bre...@chromium.org>wrote:
>>
>>>
>>> On Mon, Aug 24, 2009 at 12:49 PM, hap 497<hap...@gmail.com> wrote:
>>> > Thanks. But the picture in the document shows there is only 1
>>> > ResourceDispatcherHost and there are 2 Renderer Processes:
>>> >
>>> >
>>> http://dev.chromium.org/developers/design-documents/multi-process-architecture
>>> > And the ResourceDispatcherHost has access to both Channels for each
>>> Renderer
>>> > Process.
>>>
>>> Information about each request including the originating renderer is
>>> tacked onto each URLRequest in the form of "ExtraRequestInfo." See one
>>> of the functions in there such as
>>> ResourceDispatcherHost::OnResponseCompleted for how this is retrieved.
>>>
>>
>> Right, information such as renderer process id is available, but there are
>> no pointers to the ResourceMessageFilter in there. Using the process id,
>> you could get to the RenderProcessHost (but only on the UI thread) and from
>> there to the RMF.
>>
>>
>
> Thanks for all the answers.
>
> If ResourceMessageFilter has all the information for dispatching the
> message, why it needs to talk to ResourceDispatcherHost ( a singleton class)
> for dispatching? Looking at resource_dispatcher_host.h, I am not sure what
> centralized information it is holding so that each ResourceMessageFilter
> needs ResourceDispatcherHost for dispatching.
>
> Thank you for your help.
>
Resource loading involves interactions with a number of objects that span
all child processes (renderers, workers, plugins, etc). So while
ResourceMessageFilter does contain all of the info needed to communicate a
response back to its child process, it does not contain all of the
information to handle the request. That is where ResourceDispatcherHost
comes in. It does contain all of the info needed to fully handle the
request.
Things like... SafeBrowsingService, UserScriptListener, a centralized timer
for stats collection, the list of 'observers' to spam with info about what
requests are happening system wide, a centralized place to all things
down... etc...
Not sure we're doing this yet, but it also provides a centralized place to
prioritize requests on behalf of processA vs processB.
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
