This is still the vague plan, at least. Nobody's really looked at performance yet beyond "making new tabs sure is slow on Linux"; maybe the zygote bit would help, but it seems equally likely to me that we've got other things going wrong.
On Thu, May 7, 2009 at 2:19 PM, Dan Kegel <[email protected]> wrote: > > Is this still the plan? > > I don't see any alternative, since on Linux, when we get updated, the > old version's files are no longer available, so any old instances > still running either have to be happy with the new version's files, > or not need any files at all. > > > On Thu, Feb 5, 2009 at 11:35 AM, <[email protected]> wrote: >> I think the current plan is to have a zygote used to spawn sub processes >> in which case it should be safe to change the chrome executable while it >> is running. The running chrome process won't depend on disk for anything >> (all data files are mmapped at process start up). >> >> On Thu, 5 Feb 2009, cpu wrote: >> >>> >>> Are there any implications for sandboxing on the fork vs exec ? I >>> don't want us to paint ourselves in a corner when we implement the >>> sandbox. >>> >>> >>> On Feb 5, 9:57 am, Rahul Kuchhal <[email protected]> wrote: >>> > If file structure on Linux is anywhere like Windows than the shared >>> > library >>> > (chrome.dll on Windows) would be versioned (the dll is kept inside a >>> > version >>> > directory on Windows) but the executable itself (chrome.exe) will always >>> > live at the same place. >>> > On Linux are we going to allow Chrome updates to happen while Chrome is >>> > running? In this is what we are aiming for forking sounds great since we >>> > will end up using the same exe version and this should work as long as we >>> > know which shared library we are using with it. >>> > >>> > On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel <[email protected]> >>> > wrote: >>> > >>> > > Firefox behaves terribly upon update on Linux because >>> > > they didn't bother even trying to make distro updates >>> > > work well, and everybody uses distro packages for Firefox. >>> > > Let's avoid this same problem on Chrome for Linux. >>> > > Does that sound like a reasonable goal? We're >>> > > early enough in the port that it might not be too >>> > > hard to bake that feature in. >>> > >>> > > What would it take to survive all our files changing >>> > > out from under us? I imagine it would suffice to: >>> > >>> > > 1) open all the files we're going to need early, >>> > > and keep the handles around for when we need them >>> > >>> > > 2) for our own executables, don't exec, only fork. >>> > > That would mean using a zygote, i.e. at startup time, >>> > > fork before creating any threads, and have the initial >>> > > instance just be a factory for anybody who needs another >>> > > instance of that executable. >>> > >>> > > Is that practical, and did I miss anything? >>> > > - Dan >>> > >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
