Jens Alfke wrote: > Unfortunately, it's nearly impossible to continue a forked process on OS X > if it uses any higher-level (above POSIX) APIs. The main problem is that > Mach ports can't be replicated across the fork, so if any ports were already > open, they'll all be bogus in the new process. And all kinds of stuff in the > OS is done via IPC across Mach ports, most significantly to the window > server.
Sure, we understand that. Why does that become a concern with pre-warmed renderers in a way that it's not with the renderers we're using now? My proposal is to fork a new process, exec the renderer, and then let it bring itself up. That's exactly how we start renderers now. The only difference is that I'm suggesting we should always keep a spare one warmed up and ready to go, and we should start the initial one sooner instead of waiting for something in the browser to say "um, I'm gonna need a renderer." We can pretty much guarantee that we'll always need a renderer, let's give it a head start. I don't want to just pre-fork a process and have it sit around with its thumb up its Mach port. That wouldn't really gain us much on the Mac anyway, because our fork is relatively cheap. As I mentioned, the big losses that we experience in bringing up a new renderer process are in loading and initialization. Mark --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
