[chromium-dev] Re: Making sense of startup
On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) b...@chromium.orgwrote: It looks like everyone and their dog adds init code to the startup sequence. This takes the form of first time initialization, command line switch parsing, etc. Is there any special reason why it's done in the startup flow vs. in a static method the first time a service is created or used? All I know is there are lots of ordering dependencies, where certain classes must be initialized before others. Most of these are subtle and undocumented :( Even besides the methods you named, there are a slew of other initialization methods whose purpose is wildly unclear. When adding support for --user-agent=, I tried to understand some of this stuff better with jam's help and came to the conclusion that a lot of it was insane and should be condensed, redesigned entirely, etc. If you're cleaning up startup, definitely also look at the methods I touched when adding that switch too (a lot of them might be better places for stuff that lives in BrowserMain). 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] Qt now a possibility?
I am sure most of you have seen the news by now that Qt is switching from GPL to LGPL licensing. Does this increase the chances of a Qt Chrome on Linux instead of GTK or has too much work already been completed on the Linux GUI? --~--~-~--~~~---~--~~ 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: Qt now a possibility?
On Wed, Jan 14, 2009 at 9:15 AM, andrewg droi...@gmail.com wrote: I am sure most of you have seen the news by now that Qt is switching from GPL to LGPL licensing. Does this increase the chances of a Qt Chrome on Linux instead of GTK or has too much work already been completed on the Linux GUI? I'm no lawyer, but it appears there was already an exception list[1] for the GPL-licensed code that would've covered us anyway? So I believe this LGPL thing has no affect on us, except in its potential broader implications for the space of other software in the future. I, too, would be happy to review patches for Qt support. [1] http://doc.trolltech.com/4.3/license-gpl-exceptions.html --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] fixing CommandLine
Our CommandLine class is very confusing -- it is not a class for working with command lines, but in fact a stealth singleton that wraps the command line used to start the process. Further, since it came from Windows, it does all this string-munging and quoting that is not necessary on OS X or Linux. We need a sane way to construct cross-platform command lines and invoke subprocesses. I propose the following: 1) For the singleton use case, we change code to use a real singleton (e.g. CommandLine::Get() or even our SingletonCommandLine). 2) We extend the class to also be useful for generating command lines. Here's a taste of API (that would be folded into CommandLine): http://codereview.chromium.org/18073/diff/1/3 The function names intentionally match the old static function names above so it's easier to convert old code. Some callers are already incorrectly (by the current API) using CommandLine like this. If this is ok, I volunteer to fix all callers. (If you haven't dealt with it before, this area of the code is embarassingly prone to endless arguments, so I apologize for bringing this up again.) --~--~-~--~~~---~--~~ 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: fixing CommandLine
I don't think that it is actually *always* used as a singleton currently. As Ricardo pointed out, only the default constructor uses the CommandLine::Data singleton. The other constructors create new Data objects. This is somewhat moot though if you will be ditching the Data class. And that proposed API looks much cleaner so I'm all for it. --~--~-~--~~~---~--~~ 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: fixing CommandLine
On Wed, Jan 14, 2009 at 6:22 PM, Evan Martin e...@chromium.org wrote: Our CommandLine class is very confusing -- it is not a class for working with command lines, but in fact a stealth singleton that wraps the command line used to start the process. Further, since it came from Windows, it does all this string-munging and quoting that is not necessary on OS X or Linux. We need a sane way to construct cross-platform command lines and invoke subprocesses. I propose the following: 1) For the singleton use case, we change code to use a real singleton (e.g. CommandLine::Get() or even our SingletonCommandLine). I prefer the ::Get version myself. I was also thinking of CommandLine::ForCurrentProcess() since it might reduce some of the ambiguity that seems to crop up here. 2) We extend the class to also be useful for generating command lines. Here's a taste of API (that would be folded into CommandLine): http://codereview.chromium.org/18073/diff/1/3 The function names intentionally match the old static function names above so it's easier to convert old code. Some callers are already incorrectly (by the current API) using CommandLine like this. If this is ok, I volunteer to fix all callers. (If you haven't dealt with it before, this area of the code is embarassingly prone to endless arguments, so I apologize for bringing this up again.) I'm on the fence about this builder class since it somehow feels like overkill for this application. If we do go with the class, do we really need a vector of strings? It seems like every use (though I haven't looked at all uses) is basically. have a string append some switches use the string so that keeping the vector of strings is just a lot of mallocs and string copies with no purpose. Now that I write this, I think having the class is fine since it provides some useful scoping for these things, but I think it should just keep a string and append to it like we do currently. 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: Making sense of startup
the winsock initialization can be removed now that we have EnsureWinSockInit which should be called by any code that uses winsock. (we may not have sprinkled that in all of the right places, but you get the idea.) i really like your idea of documenting startup dependencies, and i agree that the reason for a lot of this is to deal with required orderings. if we were to try to make everything lazily init via Singleton or function statics, we'd then potentially have shutdown ordering problems as we also have to be careful about the order in which things get torn down. sometimes it is just better to lay things out carefully at startup and shutdown instead of trying to do everything in a cleverly lazy fashion. of course that doesn't work if startup (and shutdown) are treated like dumping grounds as has been the case :-( -darin On Wed, Jan 14, 2009 at 3:08 AM, Dean McNamee de...@chromium.org wrote: +1, when working on startup performance, I had a really difficult time following the startup sequence from the code. I actually relied more on the generated traces to know what was going on. Additionally, since nothing was commented, and all ordering seemed arbitrary, it was hard to tell if things were scheduled at a certain place for a reason, if the could be moved around to help startup perf, etc. It would be great at least if every piece of initialization code could have a comment that states what it's initializing, and what it depends on having been already initialized, etc. This would then help the second pass of moving the minor initialization where scheduling isn't important into better places... It is also probably currently a mess for cross platform, for example, we were initializing winsock in browsermain, which to me seems completely unrelated to this portion of code. On Wed, Jan 14, 2009 at 9:11 AM, Peter Kasting pkast...@chromium.org wrote: On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) b...@chromium.org wrote: It looks like everyone and their dog adds init code to the startup sequence. This takes the form of first time initialization, command line switch parsing, etc. Is there any special reason why it's done in the startup flow vs. in a static method the first time a service is created or used? All I know is there are lots of ordering dependencies, where certain classes must be initialized before others. Most of these are subtle and undocumented :( Even besides the methods you named, there are a slew of other initialization methods whose purpose is wildly unclear. When adding support for --user-agent=, I tried to understand some of this stuff better with jam's help and came to the conclusion that a lot of it was insane and should be condensed, redesigned entirely, etc. If you're cleaning up startup, definitely also look at the methods I touched when adding that switch too (a lot of them might be better places for stuff that lives in BrowserMain). PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
