Yes, I think that's correct. It would be possible to have two different versions running with two different profiles. I think that's OK since you're running two different profiles already.
On Thu, 5 Feb 2009, Rahul Kuchhal wrote: > Since I don't know how zygote works I will just throw it out there - what > will happen if Chrome gets updated while it is already running and user > tries to launch another instance of Chrome browser (from a shortcut or from > command line)? I am guessing if its the same profile the new chrome will > exit after sending a msg to already running browser instance. But if it is a > different profile we can potentially have two different version running with > two different profiles? > > On Thu, Feb 5, 2009 at 10: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 -~----------~----~----~----~------~----~------~--~---
