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