| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 16:22 UTC (Wed) by drag (subscriber, #31333)In reply to: Day: GNOME OS by krake Parent article: Day: GNOME OS
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.
(Log in to post comments)
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.)
|
|||||||||||||