[chromium-dev] Graceful updates on Linux

[Dan Kegel]

Firefox behaves terribly upon update on Linux because
they didn't bother even trying to make distro updates
work well, and everybody uses distro packages for Firefox.
Let's avoid this same problem on Chrome for Linux.
Does that sound like a reasonable goal?  We're
early enough in the port that it might not be too
hard to bake that feature in.

What would it take to survive all our files changing
out from under us?  I imagine it would suffice to:

1) open all the files we're going to need early,
and keep the handles around for when we need them

2) for our own executables, don't exec, only fork.
That would mean using a zygote, i.e. at startup time,
fork before creating any threads, and have the initial
instance just be a factory for anybody who needs another
instance of that executable.

Is that practical, and did I miss anything?
- Dan

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Graceful updates on Linux

[Rahul Kuchhal]

If file structure on Linux is anywhere like Windows than the shared library
(chrome.dll on Windows) would be versioned (the dll is kept inside a version
directory on Windows) but the executable itself (chrome.exe) will always
live at the same place.
On Linux are we going to allow Chrome updates to happen while Chrome is
running? In this is what we are aiming for forking sounds great since we
will end up using the same exe version and this should work as long as we
know which shared library we are using with it.

On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel  wrote:

>
> Firefox behaves terribly upon update on Linux because
> they didn't bother even trying to make distro updates
> work well, and everybody uses distro packages for Firefox.
> Let's avoid this same problem on Chrome for Linux.
> Does that sound like a reasonable goal?  We're
> early enough in the port that it might not be too
> hard to bake that feature in.
>
> What would it take to survive all our files changing
> out from under us?  I imagine it would suffice to:
>
> 1) open all the files we're going to need early,
> and keep the handles around for when we need them
>
> 2) for our own executables, don't exec, only fork.
> That would mean using a zygote, i.e. at startup time,
> fork before creating any threads, and have the initial
> instance just be a factory for anybody who needs another
> instance of that executable.
>
> Is that practical, and did I miss anything?
> - Dan
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Graceful updates on Linux

[cpu]

Are there any implications for sandboxing on the fork vs exec ? I
don't want us to paint ourselves in a corner when we implement the
sandbox.


On Feb 5, 9:57 am, Rahul Kuchhal  wrote:
> If file structure on Linux is anywhere like Windows than the shared library
> (chrome.dll on Windows) would be versioned (the dll is kept inside a version
> directory on Windows) but the executable itself (chrome.exe) will always
> live at the same place.
> On Linux are we going to allow Chrome updates to happen while Chrome is
> running? In this is what we are aiming for forking sounds great since we
> will end up using the same exe version and this should work as long as we
> know which shared library we are using with it.
>
> On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel  wrote:
>
> > Firefox behaves terribly upon update on Linux because
> > they didn't bother even trying to make distro updates
> > work well, and everybody uses distro packages for Firefox.
> > Let's avoid this same problem on Chrome for Linux.
> > Does that sound like a reasonable goal?  We're
> > early enough in the port that it might not be too
> > hard to bake that feature in.
>
> > What would it take to survive all our files changing
> > out from under us?  I imagine it would suffice to:
>
> > 1) open all the files we're going to need early,
> > and keep the handles around for when we need them
>
> > 2) for our own executables, don't exec, only fork.
> > That would mean using a zygote, i.e. at startup time,
> > fork before creating any threads, and have the initial
> > instance just be a factory for anybody who needs another
> > instance of that executable.
>
> > Is that practical, and did I miss anything?
> > - Dan
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Graceful updates on Linux

[tony]

I think the current plan is to have a zygote used to spawn sub processes
in which case it should be safe to change the chrome executable while it
is running.  The running chrome process won't depend on disk for anything
(all data files are mmapped at process start up).

On Thu, 5 Feb 2009, cpu wrote:

> 
> Are there any implications for sandboxing on the fork vs exec ? I
> don't want us to paint ourselves in a corner when we implement the
> sandbox.
> 
> 
> On Feb 5, 9:57 am, Rahul Kuchhal  wrote:
> > If file structure on Linux is anywhere like Windows than the shared library
> > (chrome.dll on Windows) would be versioned (the dll is kept inside a version
> > directory on Windows) but the executable itself (chrome.exe) will always
> > live at the same place.
> > On Linux are we going to allow Chrome updates to happen while Chrome is
> > running? In this is what we are aiming for forking sounds great since we
> > will end up using the same exe version and this should work as long as we
> > know which shared library we are using with it.
> >
> > On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel  wrote:
> >
> > > Firefox behaves terribly upon update on Linux because
> > > they didn't bother even trying to make distro updates
> > > work well, and everybody uses distro packages for Firefox.
> > > Let's avoid this same problem on Chrome for Linux.
> > > Does that sound like a reasonable goal?  We're
> > > early enough in the port that it might not be too
> > > hard to bake that feature in.
> >
> > > What would it take to survive all our files changing
> > > out from under us?  I imagine it would suffice to:
> >
> > > 1) open all the files we're going to need early,
> > > and keep the handles around for when we need them
> >
> > > 2) for our own executables, don't exec, only fork.
> > > That would mean using a zygote, i.e. at startup time,
> > > fork before creating any threads, and have the initial
> > > instance just be a factory for anybody who needs another
> > > instance of that executable.
> >
> > > Is that practical, and did I miss anything?
> > > - Dan
> > 
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Don't include render_messages.h in a header

[John Abd-El-Malek]

I've gone through the code and removed all such occurrences. This
speeds up the build from 15 to 13 minutes (using /MP on quadcore with
SSD). It also means that editing that file only rebuilds 36 files
instead of 200.

There shouldn't be any reason to include that file from a header. The
reason this has happened is that people have ended up using structs
that define the parameters of an IPC message with many parameters as
member variables in classes. If this happens, then the struct should
just be moved to its own file outside of render_messages.h.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [extensions] Extension Process Model Draft

[John Abd-El-Malek]

Looks good, one comment: previously there's been some high level
comments about how workers can be used to give extensions a long lived
context.  If this is still the case, would an extension that used a
worker & UI end up having to use two processes?

On Wed, Feb 4, 2009 at 5:49 PM, Matt Perry  wrote:
> I wrote up a short design doc covering what our extension process model will
> look like.  Feedback welcome.
> http://dev.chromium.org/developers/design-documents/extensions/process-model
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Evan Martin]

I fear we have a have a couple long threads of headers that touch
everything.  At one point we had something like: v8 bindings -> stats
table -> process_util -> process, which meant if you touched any of
our process-management code we'd rebuild all of WebKit's SVG bindings.
 :~(

For an especially painful build, try touching npapi.h.  Apparently
most of our project depends on that file.

On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek  wrote:
>
> I've gone through the code and removed all such occurrences. This
> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
> SSD). It also means that editing that file only rebuilds 36 files
> instead of 200.
>
> There shouldn't be any reason to include that file from a header. The
> reason this has happened is that people have ended up using structs
> that define the parameters of an IPC message with many parameters as
> member variables in classes. If this happens, then the struct should
> just be moved to its own file outside of render_messages.h.
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [extensions] Extension Process Model Draft

[Evan Martin]

I know that "user scripts" has a known meaning, but in the context of
this code it is a rather strange name.

  // these two are loaded into the extension process
  chrome_scripts: ["chrome/main.js"],
  toolstrip: "chrome/toolstrip.html",
  // this is loaded into renderers
  user_scripts: {

Have you considered something like "content_scripts" instead?  The
reason there were called "user" scripts before was because the user
controlled them, but here they're deep inside the extension.

On Wed, Feb 4, 2009 at 5:49 PM, Matt Perry  wrote:
> I wrote up a short design doc covering what our extension process model will
> look like.  Feedback welcome.
> http://dev.chromium.org/developers/design-documents/extensions/process-model
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] xcodebodge friendliness

[Paweł Hajdan Jr .]

I just checked in a change to xcodebodge that makes it more friendly for
people who can't remember its command names and syntax (like me). Here's a
small demo:

$ ../tools/xcodebodge/xcodebodge.py -p chrome.xcodeproj/
Information about project "chrome"
Native Targets:
image_diff
renderer
browser
unit_tests
common
ui_tests
ipc_tests
app

To add or remove files from given target, run:
xcodebodge.py -p  -t  add_source 
xcodebodge.py -p  -t  remove_source 

So, for most common operations you just have to remember the -p switch. If
it makes your work slightly easier, then great.

Paweł

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Amanda Walker]

On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
> For an especially painful build, try touching npapi.h.  Apparently
> most of our project depends on that file.

Yeah, I made that discovery last night.  Very painful.

--Amanda

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[John Abd-El-Malek]

One idea I've been thinking about is timing how long a clean build
takes, and tracking that just as we do with other performance tests.
The goal would be to notice when someone introduces an unnecessary
dependency that slows the build.  Obviously if it's needed, that's ok.

Chromium-XP does a full build each time, I wonder how easy it would be
to plot its build times?

On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
> I fear we have a have a couple long threads of headers that touch
> everything.  At one point we had something like: v8 bindings -> stats
> table -> process_util -> process, which meant if you touched any of
> our process-management code we'd rebuild all of WebKit's SVG bindings.
>  :~(
>
> For an especially painful build, try touching npapi.h.  Apparently
> most of our project depends on that file.
>
> On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek  wrote:
>>
>> I've gone through the code and removed all such occurrences. This
>> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
>> SSD). It also means that editing that file only rebuilds 36 files
>> instead of 200.
>>
>> There shouldn't be any reason to include that file from a header. The
>> reason this has happened is that people have ended up using structs
>> that define the parameters of an IPC message with many parameters as
>> member variables in classes. If this happens, then the struct should
>> just be moved to its own file outside of render_messages.h.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: xcodebodge friendliness

[Darin Fisher]

Nice change, thanks!-darin

2009/2/5 Paweł Hajdan Jr. 

> I just checked in a change to xcodebodge that makes it more friendly for
> people who can't remember its command names and syntax (like me). Here's a
> small demo:
>
> $ ../tools/xcodebodge/xcodebodge.py -p chrome.xcodeproj/
> Information about project "chrome"
> Native Targets:
> image_diff
> renderer
> browser
> unit_tests
> common
> ui_tests
> ipc_tests
> app
>
> To add or remove files from given target, run:
> xcodebodge.py -p  -t  add_source 
> xcodebodge.py -p  -t  remove_source 
>
> So, for most common operations you just have to remember the -p switch. If
> it makes your work slightly easier, then great.
>
> Paweł
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [extensions] Extension Process Model Draft

[Aaron Boodman]

On Thu, Feb 5, 2009 at 10:51 AM, Evan Martin  wrote:
> I know that "user scripts" has a known meaning, but in the context of
> this code it is a rather strange name.
>
>  // these two are loaded into the extension process
>  chrome_scripts: ["chrome/main.js"],
>  toolstrip: "chrome/toolstrip.html",
>  // this is loaded into renderers
>  user_scripts: {
>
> Have you considered something like "content_scripts" instead?  The
> reason there were called "user" scripts before was because the user
> controlled them, but here they're deep inside the extension.

Heh, we actually originally called them "content scripts" (in the
original design docs). I changed the name to user scripts because I
thought it would be more immediately understandable to extension
developers who are familiar with the existing concept.

Also, for some time, I thought the metadata controlling when
userscripts-in-extensions would be compatible with
userscripts-in-greasemonkey, so to me, it made sense to call them the
same thing. That's no longer true though, so maybe it makes sense to
go back to content_scripts.



Either way, I think we'll end up explaining this like "Chromium
extensions support  scripts (sorta like Greasemonkey)."

- a

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Erik Kay]

(arg.  reposting again)

One thing that scons is very good at is dependency analysis.  Is it
possible to get it to spit out a dependency report (which files depend
on each file in the project)?  I wonder if we might find that files
like npapi.h don't actually need to touch everything, etc.

Erik


On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
>
> I fear we have a have a couple long threads of headers that touch
> everything.  At one point we had something like: v8 bindings -> stats
> table -> process_util -> process, which meant if you touched any of
> our process-management code we'd rebuild all of WebKit's SVG bindings.
>  :~(
>
> For an especially painful build, try touching npapi.h.  Apparently
> most of our project depends on that file.
>
> On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek  wrote:
>>
>> I've gone through the code and removed all such occurrences. This
>> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
>> SSD). It also means that editing that file only rebuilds 36 files
>> instead of 200.
>>
>> There shouldn't be any reason to include that file from a header. The
>> reason this has happened is that people have ended up using structs
>> that define the parameters of an IPC message with many parameters as
>> member variables in classes. If this happens, then the struct should
>> just be moved to its own file outside of render_messages.h.
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [extensions] Extension Process Model Draft

[Matt Perry]

On Thu, Feb 5, 2009 at 10:35 AM, John Abd-El-Malek  wrote:

>
> Looks good, one comment: previously there's been some high level
> comments about how workers can be used to give extensions a long lived
> context.  If this is still the case, would an extension that used a
> worker & UI end up having to use two processes?


We haven't thought too much about this yet, but I think the answer is yes.
 We would rely on whatever system we use for workers in the normal web case,
which is looking like it will require a separate worker process.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [extensions] Extension Process Model Draft

[Aaron Boodman]

On Thu, Feb 5, 2009 at 11:29 AM, Matt Perry  wrote:
> On Thu, Feb 5, 2009 at 10:35 AM, John Abd-El-Malek  wrote:
>>
>> Looks good, one comment: previously there's been some high level
>> comments about how workers can be used to give extensions a long lived
>> context.  If this is still the case, would an extension that used a
>> worker & UI end up having to use two processes?
>
> We haven't thought too much about this yet, but I think the answer is yes.
>  We would rely on whatever system we use for workers in the normal web case,
> which is looking like it will require a separate worker process.

I thought we were moving away from reusing Workers and thinking of the
shared, long-lived context as a more-or-less normal renderer instead.

- a

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [extensions] Extension Process Model Draft

[Marshall Greenblatt]

Will it be possible to create Chrome extensions with binary components?  For
instance, Mozilla extensions can distribute and access XPCOM components.

On Wed, Feb 4, 2009 at 8:49 PM, Matt Perry  wrote:

> I wrote up a short design doc covering what our extension process model
> will look like.  Feedback welcome.
>
>
> http://dev.chromium.org/developers/design-documents/extensions/process-model
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [extensions] Extension Process Model Draft

[Aaron Boodman]

On Thu, Feb 5, 2009 at 11:51 AM, Marshall Greenblatt
 wrote:
> Will it be possible to create Chrome extensions with binary components?  For
> instance, Mozilla extensions can distribute and access XPCOM components.

We were thinking that you could use NPAPI for binary components. It's
kinda a difficult interface, so in the future we might develop
something better, but it should suffice to start.

- a

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Darin Fisher]

That shouldn't be a problem anymore since WebKit no longer depends directly
on base/.
-Darin


On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:

>
> I fear we have a have a couple long threads of headers that touch
> everything.  At one point we had something like: v8 bindings -> stats
> table -> process_util -> process, which meant if you touched any of
> our process-management code we'd rebuild all of WebKit's SVG bindings.
>  :~(
>
> For an especially painful build, try touching npapi.h.  Apparently
> most of our project depends on that file.
>
> On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek 
> wrote:
> >
> > I've gone through the code and removed all such occurrences. This
> > speeds up the build from 15 to 13 minutes (using /MP on quadcore with
> > SSD). It also means that editing that file only rebuilds 36 files
> > instead of 200.
> >
> > There shouldn't be any reason to include that file from a header. The
> > reason this has happened is that people have ended up using structs
> > that define the parameters of an IPC message with many parameters as
> > member variables in classes. If this happens, then the struct should
> > just be moved to its own file outside of render_messages.h.
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Graceful updates on Linux

[Rahul Kuchhal]

Since I don't know how zygote works I will just throw it out there - what
will happen if Chrome gets updated while it is already running and user
tries to launch another instance of Chrome browser (from a shortcut or from
command line)? I am guessing if its the same profile the new chrome will
exit after sending a msg to already running browser instance. But if it is a
different profile we can potentially have two different version running with
two different profiles?

On Thu, Feb 5, 2009 at 10:35 AM,  wrote:

> I think the current plan is to have a zygote used to spawn sub processes
> in which case it should be safe to change the chrome executable while it
> is running.  The running chrome process won't depend on disk for anything
> (all data files are mmapped at process start up).
>
> On Thu, 5 Feb 2009, cpu wrote:
>
> >
> > Are there any implications for sandboxing on the fork vs exec ? I
> > don't want us to paint ourselves in a corner when we implement the
> > sandbox.
> >
> >
> > On Feb 5, 9:57 am, Rahul Kuchhal  wrote:
> > > If file structure on Linux is anywhere like Windows than the shared
> library
> > > (chrome.dll on Windows) would be versioned (the dll is kept inside a
> version
> > > directory on Windows) but the executable itself (chrome.exe) will
> always
> > > live at the same place.
> > > On Linux are we going to allow Chrome updates to happen while Chrome is
> > > running? In this is what we are aiming for forking sounds great since
> we
> > > will end up using the same exe version and this should work as long as
> we
> > > know which shared library we are using with it.
> > >
> > > On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel 
> wrote:
> > >
> > > > Firefox behaves terribly upon update on Linux because
> > > > they didn't bother even trying to make distro updates
> > > > work well, and everybody uses distro packages for Firefox.
> > > > Let's avoid this same problem on Chrome for Linux.
> > > > Does that sound like a reasonable goal?  We're
> > > > early enough in the port that it might not be too
> > > > hard to bake that feature in.
> > >
> > > > What would it take to survive all our files changing
> > > > out from under us?  I imagine it would suffice to:
> > >
> > > > 1) open all the files we're going to need early,
> > > > and keep the handles around for when we need them
> > >
> > > > 2) for our own executables, don't exec, only fork.
> > > > That would mean using a zygote, i.e. at startup time,
> > > > fork before creating any threads, and have the initial
> > > > instance just be a factory for anybody who needs another
> > > > instance of that executable.
> > >
> > > > Is that practical, and did I miss anything?
> > > > - Dan
> > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Steven Knight]

Hi Erik--
It depends on what you really want.  SCons does have all of the
dependencies, but it doesn't keep the #include tree.

Tangible example:  if "foo.c" #includes "inc.h", and "inc.h" also #includes
both "a.h" and "b.h", the resulting dependency list actually looks like:

foo.o:   foo.c inc.h a.h b.h

It's trivial to dump that sort of information from SCons' database (there's
a "sconsign" script that will do it).

It would not show you which files #included each other, which for this
example would look something like:

foo.o:   foo.c
foo.c:   inc.h
inc.h:   a.h b.h

(SCons doesn't track those #include relationships are not actually
dependencies.)

Now that I think about it, I'm not sure how you'd use either set of
information to determine automatically that a dependency isn't needed.  The
dependencies only exist because there's actually a #include line somewhere
in the chain that will (or might) suck it into the compile.  Trying to
figure out if a given #include is somehow unnecessary for a given .o file
seems like a garbage-in-garbage-out problem; I don't see where you'd derive
the distinction that indicates one #include is necessary but another isn't.

But if someone does come up with a use for the dependency info (per the
first example above), it's easy enough to get.

--SK

On Thu, Feb 5, 2009 at 11:26 AM, Erik Kay  wrote:

>
> (arg.  reposting again)
>
> One thing that scons is very good at is dependency analysis.  Is it
> possible to get it to spit out a dependency report (which files depend
> on each file in the project)?  I wonder if we might find that files
> like npapi.h don't actually need to touch everything, etc.
>
> Erik
>
>
> On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
> >
> > I fear we have a have a couple long threads of headers that touch
> > everything.  At one point we had something like: v8 bindings -> stats
> > table -> process_util -> process, which meant if you touched any of
> > our process-management code we'd rebuild all of WebKit's SVG bindings.
> >  :~(
> >
> > For an especially painful build, try touching npapi.h.  Apparently
> > most of our project depends on that file.
> >
> > On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek 
> wrote:
> >>
> >> I've gone through the code and removed all such occurrences. This
> >> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
> >> SSD). It also means that editing that file only rebuilds 36 files
> >> instead of 200.
> >>
> >> There shouldn't be any reason to include that file from a header. The
> >> reason this has happened is that people have ended up using structs
> >> that define the parameters of an IPC message with many parameters as
> >> member variables in classes. If this happens, then the struct should
> >> just be moved to its own file outside of render_messages.h.
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Graceful updates on Linux

[tony]

Yes, I think that's correct.  It would be possible to have two different
versions running with two different profiles.  I think that's OK since
you're running two different profiles already.

On Thu, 5 Feb 2009, Rahul Kuchhal wrote:

> Since I don't know how zygote works I will just throw it out there - what
> will happen if Chrome gets updated while it is already running and user
> tries to launch another instance of Chrome browser (from a shortcut or from
> command line)? I am guessing if its the same profile the new chrome will
> exit after sending a msg to already running browser instance. But if it is a
> different profile we can potentially have two different version running with
> two different profiles?
> 
> On Thu, Feb 5, 2009 at 10:35 AM,  wrote:
> 
> > I think the current plan is to have a zygote used to spawn sub processes
> > in which case it should be safe to change the chrome executable while it
> > is running.  The running chrome process won't depend on disk for anything
> > (all data files are mmapped at process start up).
> >
> > On Thu, 5 Feb 2009, cpu wrote:
> >
> > >
> > > Are there any implications for sandboxing on the fork vs exec ? I
> > > don't want us to paint ourselves in a corner when we implement the
> > > sandbox.
> > >
> > >
> > > On Feb 5, 9:57 am, Rahul Kuchhal  wrote:
> > > > If file structure on Linux is anywhere like Windows than the shared
> > library
> > > > (chrome.dll on Windows) would be versioned (the dll is kept inside a
> > version
> > > > directory on Windows) but the executable itself (chrome.exe) will
> > always
> > > > live at the same place.
> > > > On Linux are we going to allow Chrome updates to happen while Chrome is
> > > > running? In this is what we are aiming for forking sounds great since
> > we
> > > > will end up using the same exe version and this should work as long as
> > we
> > > > know which shared library we are using with it.
> > > >
> > > > On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel 
> > wrote:
> > > >
> > > > > Firefox behaves terribly upon update on Linux because
> > > > > they didn't bother even trying to make distro updates
> > > > > work well, and everybody uses distro packages for Firefox.
> > > > > Let's avoid this same problem on Chrome for Linux.
> > > > > Does that sound like a reasonable goal?  We're
> > > > > early enough in the port that it might not be too
> > > > > hard to bake that feature in.
> > > >
> > > > > What would it take to survive all our files changing
> > > > > out from under us?  I imagine it would suffice to:
> > > >
> > > > > 1) open all the files we're going to need early,
> > > > > and keep the handles around for when we need them
> > > >
> > > > > 2) for our own executables, don't exec, only fork.
> > > > > That would mean using a zygote, i.e. at startup time,
> > > > > fork before creating any threads, and have the initial
> > > > > instance just be a factory for anybody who needs another
> > > > > instance of that executable.
> > > >
> > > > > Is that practical, and did I miss anything?
> > > > > - Dan
> > > >
> > > >
> >
> 

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Erik Kay]

(sorry for repost, gmail sucks and I have a short memory)

On Thu, Feb 5, 2009 at 2:51 PM, Steven Knight  wrote:
> Hi Erik--
> It depends on what you really want.  SCons does have all of the
> dependencies, but it doesn't keep the #include tree.
> Tangible example:  if "foo.c" #includes "inc.h", and "inc.h" also #includes
> both "a.h" and "b.h", the resulting dependency list actually looks like:
> foo.o:   foo.c inc.h a.h b.h
>
> It's trivial to dump that sort of information from SCons' database (there's
> a "sconsign" script that will do it).
> It would not show you which files #included each other, which for this
> example would look something like:
> foo.o:   foo.c
> foo.c:   inc.h
> inc.h:   a.h b.h
> (SCons doesn't track those #include relationships are not actually
> dependencies.)

Right, I figured all of the info was there.  I guess the question was
whether it was easy to do something like this:

$ scons_deps a.h
foo.c

$ scons_deps -v a.h
foo.c:inc.h:a.h

$ scons_deps -v 
foo.c:inc.h:a.h
foo.c:inc.h:b.h
bar.c:bar.h
etc.

Does such a script (or something similar) exist?  From what you're
saying, I'm assuming it's easy to write.


> Now that I think about it, I'm not sure how you'd use either set of
> information to determine automatically that a dependency isn't needed.  The
> dependencies only exist because there's actually a #include line somewhere
> in the chain that will (or might) suck it into the compile.  Trying to
> figure out if a given #include is somehow unnecessary for a given .o file
> seems like a garbage-in-garbage-out problem; I don't see where you'd derive
> the distinction that indicates one #include is necessary but another isn't.
> But if someone does come up with a use for the dependency info (per the
> first example above), it's easy enough to get.

Right, I wasn't assuming you'd be able to figure out if a given
dependency was necessary in an automated way.  The point of this would
be to emit a report that then could be examined by a human.  We could
easily munge the data and answer questions like "which header is most
depended on in the source?", or "which header file adds the most bytes
to a build?" (size in bytes * number of files included)


Erik



> On Thu, Feb 5, 2009 at 11:26 AM, Erik Kay  wrote:
>>
>> (arg.  reposting again)
>>
>> One thing that scons is very good at is dependency analysis.  Is it
>> possible to get it to spit out a dependency report (which files depend
>> on each file in the project)?  I wonder if we might find that files
>> like npapi.h don't actually need to touch everything, etc.
>>
>> Erik
>>
>>
>> On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
>> >
>> > I fear we have a have a couple long threads of headers that touch
>> > everything.  At one point we had something like: v8 bindings -> stats
>> > table -> process_util -> process, which meant if you touched any of
>> > our process-management code we'd rebuild all of WebKit's SVG bindings.
>> >  :~(
>> >
>> > For an especially painful build, try touching npapi.h.  Apparently
>> > most of our project depends on that file.
>> >
>> > On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek 
>> > wrote:
>> >>
>> >> I've gone through the code and removed all such occurrences. This
>> >> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
>> >> SSD). It also means that editing that file only rebuilds 36 files
>> >> instead of 200.
>> >>
>> >> There shouldn't be any reason to include that file from a header. The
>> >> reason this has happened is that people have ended up using structs
>> >> that define the parameters of an IPC message with many parameters as
>> >> member variables in classes. If this happens, then the struct should
>> >> just be moved to its own file outside of render_messages.h.
>> >>
>> >> >
>> >>
>> >
>> > >
>> >
>>
>> >>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Peter Kasting]

On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay  wrote:

> $ scons_deps -v 
> foo.c:inc.h:a.h
> foo.c:inc.h:b.h
> bar.c:bar.h
> etc.
>
> Does such a script (or something similar) exist?  From what you're
> saying, I'm assuming it's easy to write.


Note that you could always tell MSVC to turn on printing #include chains for
each compiled file, then compile the various files you're interested in.
 From this you could probably create a reverse-mapping if you wanted...

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[James Vega]

On Thu, Feb 05, 2009 at 04:04:58PM -0800, Peter Kasting wrote:
> On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay  wrote:
> 
> > $ scons_deps -v 
> > foo.c:inc.h:a.h
> > foo.c:inc.h:b.h
> > bar.c:bar.h
> > etc.
> >
> > Does such a script (or something similar) exist?  From what you're
> > saying, I'm assuming it's easy to write.
> 
> 
> Note that you could always tell MSVC to turn on printing #include chains for
> each compiled file, then compile the various files you're interested in.
>  From this you could probably create a reverse-mapping if you wanted...

The same can be done with gcc/g++ by passing the -H argument when
compiling.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Lei Zhang]

On Thu, Feb 5, 2009 at 4:21 PM, James Vega  wrote:
>
> On Thu, Feb 05, 2009 at 04:04:58PM -0800, Peter Kasting wrote:
>> On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay  wrote:
>>
>> > $ scons_deps -v 
>> > foo.c:inc.h:a.h
>> > foo.c:inc.h:b.h
>> > bar.c:bar.h
>> > etc.
>> >
>> > Does such a script (or something similar) exist?  From what you're
>> > saying, I'm assuming it's easy to write.
>>
>>
>> Note that you could always tell MSVC to turn on printing #include chains for
>> each compiled file, then compile the various files you're interested in.
>>  From this you could probably create a reverse-mapping if you wanted...
>
> The same can be done with gcc/g++ by passing the -H argument when
> compiling.

I did the same with -MM and parsed the results. Assuming I did it
right, the average .cc file in src/chrome/ includes about 135 header
files. The files with the most number of includes:

440 about_chrome_view.o
470 options_window_view.o
481 history_ui.o
483 user_data_dir_dialog.o
544 dns_host_info_unittest.o
601 aero_glass_non_client_view.o

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Lei Zhang]

On Thu, Feb 5, 2009 at 4:21 PM, James Vega  wrote:
>
> On Thu, Feb 05, 2009 at 04:04:58PM -0800, Peter Kasting wrote:
>> On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay  wrote:
>>
>> > $ scons_deps -v 
>> > foo.c:inc.h:a.h
>> > foo.c:inc.h:b.h
>> > bar.c:bar.h
>> > etc.
>> >
>> > Does such a script (or something similar) exist?  From what you're
>> > saying, I'm assuming it's easy to write.
>>
>>
>> Note that you could always tell MSVC to turn on printing #include chains for
>> each compiled file, then compile the various files you're interested in.
>>  From this you could probably create a reverse-mapping if you wanted...
>
> The same can be done with gcc/g++ by passing the -H argument when
> compiling.

I did the same with -MM and parsed the results. Assuming I did it
right, the average .cc file in src/chrome/ includes about 135 header
files. The files with the most number of includes:

440 about_chrome_view.o
470 options_window_view.o
481 history_ui.o
483 user_data_dir_dialog.o
544 dns_host_info_unittest.o
601 aero_glass_non_client_view.o

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Stabilization Effort Daily Report

[Jon]

*Report for 2009-2-5*



*Layout Tests*

We have been making progress again and finally broke through that 300
barrier that was driving me crazy.  We are now over 96% which is great
progress!

 [image: All+Tests=78.2][image: Want+To+Pass=96.2]


[image: History of passing tests
%]Be
sure to sign up at
http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJA&hl=en if you
are going to work on a layout test.  We don't want to step on each other's
toes.

All Tests is based on all available layout tests including those that we are
currently not trying to pass.  There are tests in this group which are known
to be bad or relate to future technologies.


Want to Pass is based on the tests that we need to be passing before we will
ship a revision of the browser.  Getting this number as high as possible is
the goal of the stabilization effort.  Some of these tests are failing due
to subtle changes that require the test to be re-baselined.



Crashers

This week I went back through the bug database looking for crashes on the
trunk.  Unfortunately, I found quite a few that should have been in stable.
 I was able to upstream one of them to WebKit and I have been trying to find
good dumps and stack traces.  Everyone who is assigned to a crasher should
be working on it.  As we saw at the Chrome Team meeting the trunk is
currently way behind the stable release.  Knocking off these key crashers is
very important.

http://code.google.com/p/chromium/issues/list?can=2&q=label:stable+label:crash+-Channel:stable


*Purify Bugs (Memory)*

We have 20 remaining Purify issues.


*Regressions*

We 11 remaining regressions.


*Other bugs*

We have 41 "other bugs" to resolve.


So our bug burndown chart looks like this:

  For now it would be great to concentrate on the crashers.  We don't want
to see attrition from our dev channel.  Also, keep in mind that this does
not include the work on Layout Tests.

You will find a lot more information about the Stabilization effort on the
Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[Evan Martin]

On Thu, Feb 5, 2009 at 4:35 PM, Lei Zhang  wrote:
> I did the same with -MM and parsed the results. Assuming I did it
> right, the average .cc file in src/chrome/ includes about 135 header
> files. The files with the most number of includes:
>
> 440 about_chrome_view.o
> 470 options_window_view.o
> 481 history_ui.o
> 483 user_data_dir_dialog.o
> 544 dns_host_info_unittest.o
> 601 aero_glass_non_client_view.o

What we really need is some sort of graph of includes, so we could
find long chains.  From this list I don't know which headers are most
at fault.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Debugging the renderer process on OS X

[Jeremy Moskovich]

Just a quick note, since this may be generally useful:

If you pass the --renderer-startup-dialog when running the browser (or the
unit tests) then any spawned render process will print a message to stdout
with it's pid and then call pause().

XCode doesn't like debugging multiple processes, so what I've done up till
now is launch from the command line with the above flag and then do a
Run->Attach To Process->Process Id... in XCode to actually attach to the
renderer process.  I can then hit continue and we're off...

In general, Chrome's process structure propagates command line flags from
parent to child, so any flags you pass to the browser on startup will be
passed to child processes, this is also useful when debugging the renderer.

I'll post more detailed notes to the wiki timorrow...

Best regards,
Jeremy

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Debugging the renderer process on OS X

[Marc-Antoine Ruel]

FYI, on windows, you use --wait-for-debugger and use the macro at
http://code.google.com/p/chromium/wiki/WindowsVisualStudioMacros#Automatically_grab_chromium_child_processes

If XCode can be automated, you could probably achieve the same thing.

M-A

On Thu, Feb 5, 2009 at 4:57 PM, Jeremy Moskovich  wrote:
> Just a quick note, since this may be generally useful:
>
> If you pass the --renderer-startup-dialog when running the browser (or the
> unit tests) then any spawned render process will print a message to stdout
> with it's pid and then call pause().
>
> XCode doesn't like debugging multiple processes, so what I've done up till
> now is launch from the command line with the above flag and then do a
> Run->Attach To Process->Process Id... in XCode to actually attach to the
> renderer process.  I can then hit continue and we're off...
>
> In general, Chrome's process structure propagates command line flags from
> parent to child, so any flags you pass to the browser on startup will be
> passed to child processes, this is also useful when debugging the renderer.
>
> I'll post more detailed notes to the wiki timorrow...
>
> Best regards,
> Jeremy
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Debugging the renderer process on OS X

[John Abd-El-Malek]

On Thu, Feb 5, 2009 at 4:57 PM, Jeremy Moskovich  wrote:
> Just a quick note, since this may be generally useful:
>
> If you pass the --renderer-startup-dialog when running the browser (or the
> unit tests) then any spawned render process will print a message to stdout
> with it's pid and then call pause().
>
> XCode doesn't like debugging multiple processes, so what I've done up till
> now is launch from the command line with the above flag and then do a
> Run->Attach To Process->Process Id... in XCode to actually attach to the
> renderer process.  I can then hit continue and we're off...
>
> In general, Chrome's process structure propagates command line flags from
> parent to child, so any flags you pass to the browser on startup will be
> passed to child processes, this is also useful when debugging the renderer.

BrowserRenderProcessHost::switch_names determines which flags are
propagated (you might be aware of it, but want to make sure that
others are too).

>
> I'll post more detailed notes to the wiki timorrow...
>
> Best regards,
> Jeremy
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Debugging the renderer process on OS X

[Jeremy Moskovich]

FYI, this just describes how things are hacked up to work at the moment for
the benefit of people trying to bring stuff up.

I assume that there are better ways to do this in the long run.

Best regards,
Jeremy

On Thu, Feb 5, 2009 at 4:57 PM, Jeremy Moskovich wrote:

> Just a quick note, since this may be generally useful:
>
> If you pass the --renderer-startup-dialog when running the browser (or the
> unit tests) then any spawned render process will print a message to stdout
> with it's pid and then call pause().
>
> XCode doesn't like debugging multiple processes, so what I've done up till
> now is launch from the command line with the above flag and then do a
> Run->Attach To Process->Process Id... in XCode to actually attach to the
> renderer process.  I can then hit continue and we're off...
>
> In general, Chrome's process structure propagates command line flags from
> parent to child, so any flags you pass to the browser on startup will be
> passed to child processes, this is also useful when debugging the renderer.
>
> I'll post more detailed notes to the wiki timorrow...
>
> Best regards,
> Jeremy
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Don't include render_messages.h in a header

[James Vega]

On Thu, Feb 05, 2009 at 04:49:34PM -0800, Evan Martin wrote:
> 
> On Thu, Feb 5, 2009 at 4:35 PM, Lei Zhang  wrote:
> > I did the same with -MM and parsed the results. Assuming I did it
> > right, the average .cc file in src/chrome/ includes about 135 header
> > files. The files with the most number of includes:
> >
> > 440 about_chrome_view.o
> > 470 options_window_view.o
> > 481 history_ui.o
> > 483 user_data_dir_dialog.o
> > 544 dns_host_info_unittest.o
> > 601 aero_glass_non_client_view.o
> 
> What we really need is some sort of graph of includes, so we could
> find long chains.  From this list I don't know which headers are most
> at fault.

The raw output gives that sort of display

Compiling Hammer/dbg/obj/chrome/app/chrome_exe_main_gtk.o
. /home/jamessan/src/chromium/src/base/at_exit.h
.. /usr/include/c++/4.3/stack
... /usr/include/c++/4.3/deque
 /usr/include/c++/4.3/bits/stl_algobase.h
. /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h
.. /usr/include/c++/4.3/i486-linux-gnu/bits/os_defines.h
... /usr/include/features.h
 /usr/include/sys/cdefs.h
. /usr/include/bits/wordsize.h
 /usr/include/gnu/stubs.h
. /usr/include/bits/wordsize.h
. /usr/include/gnu/stubs-32.h
.. /usr/include/c++/4.3/i486-linux-gnu/bits/cpu_defines.h
. /usr/include/c++/4.3/cstddef
.. /usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h

so it shouldn't be too bad to generate such information.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] This week's porting progress!

[Mike Pinkerton]

Just wanted to give a quick update on the progress we've made over the
last week in the mac/linux porting effort. I'll let the linux folks
followup with exactly what they have working and focus on what's
working for Mac.

We made a list early in the week of the key classes on the critical
path to getting a renderer launching and showing bits on the screen.
Our goal was to have a renderer being spawned by launching the browser
by the end of this week. The list is now almost all green and as of
this morning we hit our goal (one day early!) to have renderer
processes launched. In fact, we launch a new renderer with each tab,
and when the tab is closed, the renderer goes away!! You can see it
come and go in Activity Monitory. All this goes through the
cross-platform infrastructure with a Cocoa front-end.

We don't (yet) have the renderer doing anything besides receiving some
initialization IPC messages, that work will arrive in the coming days
as we get RenderView hooked up. It's been a group effort, kudos to
everyone for pulling together and helping get browser and renderer
operational!

-- 
Mike Pinkerton
Mac Weenie
pinker...@google.com

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] How many GDI handles are reasonable?

[Ian Fette]

Once again, my laptop is refusing to stand by and Windows is throwing up
warning dialogs about "Insufficient system resources exist to complete the
API." Currently Chrome is sucking down a healthy 1043 gdi handles according
to gdiview, 647 of which appear to be font handles...
What is a reasonable number to expect Chrome to be using? Is 647 font
handles indicative of a leak? For reference, I have 23 chrome processes
running, and a healthy (or unhealthy?) number of tabs.

-Ian

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: How many GDI handles are reasonable?

[Brett Wilson]

On Thu, Feb 5, 2009 at 9:29 PM, Ian Fette  wrote:
> Once again, my laptop is refusing to stand by and Windows is throwing up
> warning dialogs about "Insufficient system resources exist to complete the
> API." Currently Chrome is sucking down a healthy 1043 gdi handles according
> to gdiview, 647 of which appear to be font handles...
> What is a reasonable number to expect Chrome to be using? Is 647 font
> handles indicative of a leak? For reference, I have 23 chrome processes
> running, and a healthy (or unhealthy?) number of tabs.

Is 647 font handles across all chrome processes? If that's across all
23 processes, it's not a problem. 1000 GDI objects is a lot and more
than normal, but it depends on what sites you've been visiting because
of the font cache. For reference, I've got <200 GDI objects per chrome
process, and I have two visual studio instances open and each is using
750 GDI objects.

Brett

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: How many GDI handles are reasonable?

[Ian Fette]

Across all. The most of any one process (I think it was the browser process,
but not 100% sure, could be a long-lived renderer) was something like 300
total handles, 150 of which were font.

On Thu, Feb 5, 2009 at 10:11 PM, Brett Wilson  wrote:

> On Thu, Feb 5, 2009 at 9:29 PM, Ian Fette  wrote:
> > Once again, my laptop is refusing to stand by and Windows is throwing up
> > warning dialogs about "Insufficient system resources exist to complete
> the
> > API." Currently Chrome is sucking down a healthy 1043 gdi handles
> according
> > to gdiview, 647 of which appear to be font handles...
> > What is a reasonable number to expect Chrome to be using? Is 647 font
> > handles indicative of a leak? For reference, I have 23 chrome processes
> > running, and a healthy (or unhealthy?) number of tabs.
>
> Is 647 font handles across all chrome processes? If that's across all
> 23 processes, it's not a problem. 1000 GDI objects is a lot and more
> than normal, but it depends on what sites you've been visiting because
> of the font cache. For reference, I've got <200 GDI objects per chrome
> process, and I have two visual studio instances open and each is using
> 750 GDI objects.
>
> Brett
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: How many GDI handles are reasonable?

[Brett Wilson]

On Thu, Feb 5, 2009 at 10:26 PM, Ian Fette  wrote:
> Across all. The most of any one process (I think it was the browser process,
> but not 100% sure, could be a long-lived renderer) was something like 300
> total handles, 150 of which were font.

I think that should be no problem.

Brett

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: How many GDI handles are reasonable?

[Darin Fisher]

Does your machine start to behave properly once you close a tab or two?
-Darin


On Thu, Feb 5, 2009 at 9:29 PM, Ian Fette  wrote:

> Once again, my laptop is refusing to stand by and Windows is throwing up
> warning dialogs about "Insufficient system resources exist to complete the
> API." Currently Chrome is sucking down a healthy 1043 gdi handles according
> to gdiview, 647 of which appear to be font handles...
> What is a reasonable number to expect Chrome to be using? Is 647 font
> handles indicative of a leak? For reference, I have 23 chrome processes
> running, and a healthy (or unhealthy?) number of tabs.
>
> -Ian
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---