| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 12:40 UTC (Wed) by Mog (subscriber, #29529)In reply to: Day: GNOME OS by drag Parent article: Day: GNOME OS
Something I don't understand : why anyone would expect a browser session to continue fine after an update ?
Windows gave us the expectation of a reboot after IE updates (I know, this may not be mandatory nowadays but old habits die slowly). On my Linux boxes, I close all applications, especially browsers, before running 'yum update'.
(Log in to post comments)
Day: GNOME OS Posted Aug 8, 2012 13:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Really? That sounds terribly disruptive. I never close a thing before doing updates (unless the update is huge, e.g. pushing all of KDE from 4.7 to 4.8 or something like that, in which case I generally log in again afterwards), and have never had trouble.
Day: GNOME OS Posted Aug 8, 2012 14:10 UTC (Wed) by drag (subscriber, #31333) [Link]
> Something I don't understand : why anyone would expect a browser session to continue fine after an update ?
Well the application or user is given no notification that a update was performed for most (if not all) Linux systems unless the user is the one that did the update itself.
If it's a single user environment then it's not that big of deal, but I suppose it can cause headaches unless the administrator makes sure to upgrade the system while everybody is logged out.
Day: GNOME OS Posted Aug 8, 2012 14:43 UTC (Wed) by krake (subscriber, #55996) [Link]
If the software depends on anything not changing after startup, it could monitor those files.
I believe that this is possible nowadays. Might even be possible to monitor the application's installation directory as a whole
Day: GNOME OS Posted Aug 8, 2012 16:22 UTC (Wed) by drag (subscriber, #31333) [Link]
yeah. Inotify and such. I believe that sort of thing is what they Zygote process for (as mentioned in the blog post), which is extra steps that they don't have to do on other systems.
The code used to do such things is suppose to be rather ugly, but unfortunately Google has terminated it's code search stuff and thus the links from his post showing what Chrome does is broken. I don't have time to hunt down the details myself right now.
Day: GNOME OS Posted Aug 8, 2012 20:08 UTC (Wed) by nix (subscriber, #2304) [Link]
Nah, the Zygote process does nothing as crazy as inotify. It's just a run mode of the chrome binary where it does nothing but listen for requests to fork off children to do other work. Thus, it ensures that those children are all the same instance of the same binary, so are guaranteed to be able to engage in IPC with each other (and with the master browser process) smoothly.
The thing is, a forking architecture like this is a good architecture for other reasons, compared to a plain exec() architecture. Among other things, it means that relocation happens only once, so it saves memory because pages dirtied by relocations are dirtied only once, and it saves time because relocation happens just once, at Chrome startup (an important consideration when the binary is 110Mb). KDE 3 used exactly this architecture just to minimize relocation overhead.
Again, this thing is *five hundred lines*. It's *trivial*. I've written similar things in under a day. And people are proposing massive invasive changes to every program storing state in /etc, and massive invasive changes to the way updates are carried out, to save on the terrible overhead of writing something tiny like this. Why? I am baffled.
Day: GNOME OS Posted Aug 8, 2012 22:26 UTC (Wed) by walters (subscriber, #7396) [Link]
<p>Why don't you go out and patch every application to do it then? I think you'll quickly find that it's <b>insanely tedious</b> for application authors to have to keep a file descriptor open on every file they use.</p>
<p>What's even better - it's <b>still racy</b>. If the user launches an application while an update is happening, the app can get half of the old files, and half of the new. There is no way to solve this without coordination at every layer of the stack.</p>
Day: GNOME OS Posted Aug 8, 2012 23:00 UTC (Wed) by nix (subscriber, #2304) [Link]
Have you responded to the wrong comment? There's nothing in the zygote model requiring file descriptors to be kept open to anything at all, and it's not racy if you keep each application in its own root (as nixos does: I'd agree this is one of the things it gets right), because the binaries and non-shared datafiles for a given package are never overwritten.
In fact with only a few exceptions (e.g. Perl if you want to use CPAN), you can mark such subtrees immutable and nothing whatsoever breaks. (I've been doing this for years.)
Yet again, this seems like a massive invasive change for very nearly undetectable benefit -- and it still doesn't solve the only instance of this problem that I can ever recall encountering, the 'updated application state in your home directory breaking downgrade' problem.
It's a shame I'll not be at LPC or we could have a good argument over this :)))
Day: GNOME OS Posted Aug 9, 2012 15:41 UTC (Thu) by arafel (subscriber, #18557) [Link] I think you might have misread the blog post: This process opens every file we might use and then waits for commands from the main process. When it's time to make a new subprocess we ask the helper, which forks itself again as the new child. By virtue of always forking from the same initial process, we guarantee that we are always running the same code; even if the files we opened are replaced by a system update our handle on them is the handle for the previous file.
Day: GNOME OS Posted Aug 10, 2012 8:16 UTC (Fri) by nix (subscriber, #2304) [Link]
Oh yes, true enough. Of course the most important part of this is the 'always running the same code' part. You don't have to hold the files open: if there are lots of little ones you might prefer to suck them into memory instead.
(Obviously this model will not apply to everything, but it does in fact apply to a lot. You need an abstraction around file I/O to do it, but Chrome already *has* that, and thanks to libio and open_memstream() anything can get it quite easily, without major rewrites.)
|
|||||||||||||