[chromium-dev] Re: Graceful updates on Linux
I have no idea what I'm talking about, but I just wanted to comment that on Linux when firefox is updated while I'm running, things start getting really weird and it generally becomes unusable pretty quickly...no idea why, but I assume it has something to do with its resources being deleted out from under it and the caches of such items eventually going away and it getting very confused. Hopefully whatever we do won't suffer such problems. On Thu, May 7, 2009 at 2:39 PM, Evan Martin wrote: > > 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 > 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, 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 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 > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
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 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, 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 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 >>> > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
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, 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 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
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, 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 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 > > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
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, 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 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 > 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
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 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
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 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
