On Thu, Jun 11, 2009 at 5:13 PM, Stuart Morgan <[email protected]>wrote:
> > 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. Personally this seems like the only sane way to do it. Even if you bump the limits, you will hit pretty major slow downs in most OS's (last time I saw anyone try). > 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
