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,
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
I have no idea what I'm talking about, but hand wavingI 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
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
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 kuch...@chromium.org wrote:
If file structure on Linux is anywhere like Windows than the shared library
(chrome.dll on
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
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
