[chromium-dev] Throttling URLRequestFileJobs rate?
I'm working on getting the Intl2 test set from the page cycler up and running on the Mac, which currently crashes very quickly. It turns out that one of the test pages has hundreds of images on it, and we simultaneously make hundreds of URLRequestFileJobs to load them. Each of those uses a SharedMemory for communication, each of which requires a file descriptor. This test page generates enough requests at once that we blow out the file descriptor limit (which defaults to 256 on the Mac) and fall apart. It's tempting to say that we should just a) bump up the limit, and b) make failure to create a SharedMemory non-fatal At least some degree of b) is probably a good idea, but it's not entirely clear that we *want* all the layers involved to silently accept failure. Even if we do, local pages with more images than whatever limit we set in a) won't load correctly, and making that limit too high can get ugly. A seemingly better option would be to limit the number of simultaneous URLRequestFileJobs we will allow. I assume we have plumbing in place to deal with limiting the number of simultaneous URLRequestJobs we make per server; is it flexible enough that it could be extended to handle file URLs as well? If so, is there any reason that would be a bad idea? (And can someone point me to the relevant code?) -Stuart --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Thu, Jun 11, 2009 at 7:45 PM, Darin Fisher wrote: > It seems like this issue, since it is about the shared memory used for > streaming resources to a renderer, is not particular to file://. It could > happen with http:// as well assuming we had a fast enough network or a janky > enough local system, right? I was assuming that in most cases the max-connections-per-server would tend to prevent us from getting to that point, but it's probably possible given the right circumstances. -Stuart --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Thu, Jun 11, 2009 at 8:03 PM, Michael Nordman wrote: > Sounds like the underlying issue is not the number of requests (or > type of request), but the number of SharedMemory instances in use on > behalf of request handling at any one time. True; I'll take a look at how else SharedMemory is used, and where I can introduce delays/blocking without causing problems for handling of other in-flight requests. > Also, 256 is a pretty low limit. Dialing it up a few notches (say to 1024) to improve the performance of a better overall solution certainly isn't an issue. -Stuart --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Fri, Jun 12, 2009 at 6:59 AM, Dan Kegel wrote: > Don't you need root for that? Changing the soft limit doesn't require root, and there's apparently no hard limit at all on file descriptors (at least as of Leopard; I don't think that was always true). -Stuart --~--~-~--~~~---~--~~ 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: Login name auto-fill code
On Fri, Jun 12, 2009 at 7:46 AM, Lucius Fox wrote: > Can you please tell me where is the code for 'auto-fill' login name > for Gmail on MacOS X? What part specifically? There are a number of classes involved in login autofill (assuming you are talking about the password manager, and not Gmail itself filling the username based on cookies). I'm still actively writing the password storage system on the Mac, so if you are asking because you want to do development in that area please follow up with me off-list. If you just want to write code using the password system, you'd want to use the cross-platform interfaces: either PasswordManager/PasswordFormManager, or PasswordStore, depending on what you are trying to accomplish. -Stuart --~--~-~--~~~---~--~~ 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: Login name auto-fill code
On Fri, Jun 12, 2009 at 11:36 AM, Stefan Nuxoll wrote: > Slightly offtopic, but what are you planning to use as the store on OS > X? The keychain? Short and oversimplified answer: yes. Long answer: http://docs.google.com/Doc?id=dfhbsm63_0cx9h7fsz&hl=en -Stuart --~--~-~--~~~---~--~~ 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: Crash reporting and about:crash.
On Tue, Jun 16, 2009 at 2:32 PM, Scott Hess wrote: > So, I'm inclined to mark it WontFix, except that then searches in the > Issues database won't find it. Do we think it's something people are actually likely to search for? The crash aggregator will still have the bug number listed for that stack, and that seems like the most likely (only?) place someone would be inspired to look for a bug about it in the first place. -Stuart --~--~-~--~~~---~--~~ 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 to get a faster/smaller checkout?
On Wed, Jul 15, 2009 at 11:26 PM, Hua Su wrote: > Is there any official configuration file (the > .gclient file) for win32 only checkout or linux/mac only checkout, which > only checkouts minimum files for the specified platform? Platform-specific source is scattered around, and makes up a very small fraction of the total repository size (a substantial amount of which is tests, not source code), so that would take a lot of work to maintain for very little benefit. You'd be better off looking for the really large parts of of the repository and trimming the parts of those that you don't need for your development, rather than trying to get something that removes absolutely everything that you don't need. Besides, just because you are on Windows doesn't mean you won't need to make changes to other platform files during development. If all you are doing is *building* Chromium, not doing development, excluding the big test directories will be the biggest win by at least an order of magnitude or two. -Stuart --~--~-~--~~~---~--~~ 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: Question about chromium sandbox on Mac OSX
On Thursday, July 30, 2009, n179911 wrote: > I am trying to see what it the current setting in chromium. I can't > find that in http://renderer.sb or when sandbox_init() is called. As TVL said in his earlier reply, renderer.sb *is* the current setting. We use a custom set of allow/deny rules rather than one of the pre-canned defaults. > And then I would want to see if I can switch it to > 'kSBXProfilePureComputation' > and see what may break. Reading renderer.sb should give you exactly that information; all of the exclusions there were added for a reason (documented in the file). The design doc you are reading sounds like it hasn't been updated since the sandbox was actually implemented; it should probably be updated. -Stuart --~--~-~--~~~---~--~~ 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 to disable plugin support in chromium on Mac OSX
On Tue, Aug 4, 2009 at 8:37 PM, n179911 wrote: > Can you please tell me how can I disable plugin support in my own > chromium build on Mac OSX so that when I execute chomium in XCode > flash plugin is not enabled? --disable-plugins -Stuart --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 3:36 PM, Dean McNamee wrote: > Note: Firefox on OSX selects all on single click. So there isn't a > clear answer on OSX either. Firefox has historically tended to favor "do what Firefox does on other platforms" over "follow the platform standard". In other cases, it does the wrong thing on the Mac simply because the behavior was written on Windows as cross-platform code and nobody has gotten around to fixing it for the Mac yet--text editing in particular has many examples of this. "Firefox does it differently" should never be an argument that something isn't an established standard on the Mac. -Stuart --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 4:12 PM, Dean McNamee wrote: > My argument was just that I know of only 2 frequently used URL bars in > browser. Safari, and Firefox. They differ in their behavior. I > don't know how you have an established standard when you only have a > few reference points, and one of the major ones doesn't follow it. I'm not coming at this from the perspective that this is a new control with no behavioral expectations; as others have already said, many people expect the URL bar to behave like a text field, since it looks and acts like one in most other respects. From my perspective there is a standard because I expect a certain behavior from clicking in something that looks like a text field. I understand the argument from the other side and I'm not trying to argue there's no merit in breaking from user expectations on a platform when there is a really compelling reason. My point is simply that "Firefox does it on the Mac" is not a good counter-argument for "Mac user expect a certain behavior", because Firefox does not behave the way Mac users expect in a number of respects. We should not assume that just because Firefox does something on the Mac that the majority of Mac users would expect, or be happy with, that behavior. -Stuart --~--~-~--~~~---~--~~ 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: Copying of profiles across systems
On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote: > - Is "profile platform independence" a guiding principle? > [...] > - Is it worth rewriting today's code that doesn't conform It didn't seem to be when I asked about password storage a while back. Passwords aren't even portable from machine to machine--and I would be strongly opposed to making the password storage system platform agnostic, since it would mean abandoning an important piece of OS integration (including transparent password portability across browsers) on the Mac. That's not to say that we couldn't aim for making most of a profile portable, but I would be sad if we made a hard-and-fast rule that everything must be completely portable even at the cost of platform integration. -Stuart --~--~-~--~~~---~--~~ 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: Platform parity
On Wed, Sep 2, 2009 at 12:41 PM, Jens Alfke wrote: > Yeah, password management on Mac OS is done through the system > "Keychain Access" app; we don't need a custom UI for that. For various reasons we will be using custom UI, it's just not written yet (there's a bug tracking it). -Stuart --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
On Mon, Dec 7, 2009 at 11:21 AM, oshima wrote: > Oh, by the way, i found that the same thing is happening on mac side as > well, > but I'm not familiar with mac. Can someone take care of mac side? The process for disabling tests under valgrind is identical on the Mac, so you should be able to do it exactly the same way. If you still need someone else to do it I can take care of it later this week. The change to the script should definitely not be landed while there are still known failing tests on either platform though. -Stuart -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
On Tue, Dec 8, 2009 at 1:05 PM, oshima wrote: > Ok, so mac is using the same script, correct? Yep, same script. > I can make a changelist, but I need > a way to test it on mac. Can you or someone else help me on this? Sure, although testing the script change on the Mac isn't the tricky part; the difficult part is going over all the recent Mac valgrind bot logs and making sure you have suppressed all the tests that are currently failing there. -Stuart -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
