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 --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
