On Thu, Jun 11, 2009 at 7:45 PM, Darin Fisher <[email protected]> wrote:
> 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. 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 >> >> >> >> > > Hmm... we have a couple limiters already: > > 1- FileStream uses a thread pool to read files asynchronously to the > caller. That thread pool is limited in size. > > 2- ResourceDispatcherHost limits the number of data payloads it will send > to a renderer at any given time. It looks for ACKs from the renderer, and > if it does not get them fast enough, then it backs off. > > 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? > > -Darin > I meant to add: so tweaking #2 would probably work here. -Darin --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
