On Thu, Jun 4, 2009 at 12:35 AM, Mike Belshe <mbel...@google.com> wrote:
>
>
> On Thu, Jun 4, 2009 at 12:30 AM, Meryl Silverburgh
> <silverburgh.me...@gmail.com> wrote:
>>
>> On Wed, Jun 3, 2009 at 11:09 PM, Mike Belshe <mbel...@google.com> wrote:
>> >
>> >
>> > On Wed, Jun 3, 2009 at 10:40 PM, Meryl Silverburgh
>> > <silverburgh.me...@gmail.com> wrote:
>> >>
>> >> On Tue, Jun 2, 2009 at 5:00 PM, Brett Wilson <bre...@chromium.org>
>> >> wrote:
>> >> > On Tue, Jun 2, 2009 at 4:57 PM, Meryl Silverburgh
>> >> > <silverburgh.me...@gmail.com> wrote:
>> >> >>
>> >> >> I am reading this document
>> >> >>
>> >> >>
>> >> >> "http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code";
>> >> >> about chromium source code:
>> >> >> It said:
>> >> >>
>> >> >> renderer: Code for the subprocess in each tab. This embeds WebKit
>> >> >> and
>> >> >> talks to browser for I/O.
>> >> >>
>> >> >> Does that mean chromium do not use the HTTP stack/library that
>> >> >> Webkit
>> >> >> is using?
>> >> >
>> >> > WebKit uses different HTTP stacks depending on the port. We use a
>> >> > different one than any other ports.
>> >> >
>> >> >> And does that mean all the I/O of each tab (webkit renderer) will be
>> >> >> sent to 'browser' for I/O, and there is 1 I/O thread in the browser
>> >> >> to
>> >> >> handle the I/O requests from ALL tab?
>> >> >
>> >> > Correct.
>> >> >
>> >>
>> >> That you. But if all I/O of the tab will be sent to and queued up in 1
>> >> I/O thread in 'browser',
>> >> will that become the bottleneck (as supposed to each tab has its own
>> >> i/o thread and each can load thing independently)?
>> >
>> > The rule is that the work done on the io thread needs to be very very
>> > quick.
>> > So far, we've been reasonably successful at that. We use automated
>> > tests
>> > to search for regressions.
>> > But these are just theories. Run it in the profiler, and see for
>> > yourself
>> > if it works well :-)
>> >
>>
>> Thank you for your clarification.
>> If i understanding correctly, I/O thread needs to http request network
>> resources (e.g. image files, js files, css files). And how fast that
>> http request is done is dependent on how far the other end sending the
>> file back, right? So it is not up to chromium find each i/o request
>> very very quick. Am i right?
I think the confusion here is you might be assuming that Chromium
handles the I/O synchronously. Chromium handles it asynchronously, in
chunks if necessary. Therefore, if the other end is not sending the
data slowly, the Chromium I/O thread only reads as much as is
available. Then it handles other I/O tasks or goes idle until more
data becomes available. It does not block the I/O thread while
waiting for servers to send data.
>
> Sure, but the thread is completely idle while we wait for the network and
> can therefore do other things. The amount of CPU to fetch network resources
> is tiny compared to the time to render them. The IO thread is effectively a
> dispatcher here; he gets the network requests started, and does mild
> processing of data when it arrives. But he hands the real work to the
> renderer and the webkit thread.
> Again, if you think there is a problem, open it up in a profiler. I've run
> the profiler many times, and I don't think this is a bottleneck.
> Mike
>
>>
>>
>>
>>
>> >>
>> >> And does browser I/O thread gives priority to I/O from the current
>> >> active tab (the only tab which is in the foreground)?
>> >
>> > If it ever profiles as a bottleneck, then we should definitely add
>> > priorities. Right now, we don't do much.
>> > Background tabs do take background priorities, which indirectly helps.
>> > Mike
>> >
>> >>
>> >>
>> >>
>> >> > Brett
>> >> >
>> >>
>> >> >>
>> >
>> >
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
