The update might be started by the distro in this case, but there is no reason that Firefox cannot just keep an fd on the resource files open and use that instead of the updated files. Either that or keep things compatible so it can use the new files. Not being able to use the browser after an update is inexcusable.
> there is no reason that Firefox cannot just keep an fd on the resource files open and use that instead of the updated files
If you check what processes you've running, you'll see that firefox has many of them. I'm not going to grep the sources but I believe the ones with the "-contentproc" flag are started with an exec call as needed, and I'm not aware of an exec that works with fds. It requires a path, it executes the binary at that path, and that binary in turn loads a bunch of files it needs. It's all going to blow up if your parent and child processes are running different versions of the program.
Keeping parts of a program compatible with arbitrary versions of other parts of the same program is virtually impossible. Go ahead, checkout 50% of your files from some random version of your project thousands of commits ago while keeping the rest at master, and see if it still compiles and runs correctly.
> If you check what processes you've running, you'll see that firefox has many of them. I'm not going to grep the sources but I believe the ones with the "-contentproc" flag are started with an exec call as needed, and I'm not aware of an exec that works with fds. It requires a path, it executes the binary at that path, and that binary in turn loads a bunch of files it needs. It's all going to blow up if your parent and child processes are running different versions of the program.
That firefox is set up in a way that does not work when replacing the files while running does not meat that it cannot be setup differently. For example you could have one process paused after loading all needed libraries and opening all resource archives and then just fork from that.
NB: You can actually execve the original executable under Linux via /proc/self/exe - while it behaves somewhat like a symlink to e.g. show the original path under ls / readlink, reading from it behaves like a hardlink to the original inode. This does not solve shared libraries however (but does Firefox really need to link its own libraries dynamically?) or resources (you could sendfd them to the new process if you really wanted to go with exec).
> Keeping parts of a program compatible with arbitrary versions of other parts of the same program is virtually impossible. Go ahead, checkout 50% of your files from some random version of your project thousands of commits ago while keeping the rest at master, and see if it still compiles and runs correctly.
The most sensible solution would be to keep all parts in sync, which is possible even if the copies on the filesystem changed. However, you could also have a stable API between the browser binary and the javascript parts if you wanted - that is a far cry from mixing arbitrary source files.
Keep in mind that browsers have become more like a mini-OS and should not get away with behavior common in normal applications but instead should provide stability guarantees more like an OS. And you definitely don't need to reboot because the kernel has been updated on the filesystem.
> For example you could have one process paused after loading all needed libraries and opening all resource archives and then just fork from that.
Plausible I guess, but also seems like a lot of effort to work around broken distros. Actually calling exec has tangible benefits too, e.g. it allows each process to have its address space randomized.
> However, you could also have a stable API between the browser binary and the javascript parts if you wanted - that is a far cry from mixing arbitrary source files.
Yes but the problem here is stable API and ABI between the browser binary and.. the browser binary. IPC within a binary is hardly ever written assuming a stable ABI, it'll just constrain the project way too much.
> And you definitely don't need to reboot because the kernel has been updated on the filesystem.
I feel like the kernel isn't really a fair comparison since it's relatively self-contained and you generally don't have multiple instances of the kernel talking to each other using IPC.
But go ahead, update your modules and see if you can still load them on your old kernel without rebooting. No, you can't. Same problem.
Unfortunately OSes today tend to have many dynamically loaded parts that require restarts if you want to keep everything working after updates.
AFAIK Chrome behaves the same. You can't update a browser cleanly while it is running. In Windows is is handled correctly because both browsers are updated in the background when the browser is closed, but in Linux-style environments this work is done by the package manager. When the package manager stomps over a running instance of Firefox, the old behavior was to crash. At least, now Firefox can detect what happened and keep the active tabs running while instructing you to please restart the browser.
Regarding private tabs, one workaround would be to store the whole window as a bookmark folder (right click on empty tab area, select all tabs, store as bookmarks).
The package manager does not stomp over the running instance but only replaces the files. The original files even remain on the disc (but without any name) as long as they are open. It is firefox that is designed to have to re-open those files during runtime - but that is not inherently required. Before Firefox went multi-process it handled package updates just fine and there is no technical reason why it can't still do that.
>Before Firefox went multi-process it handled package updates just fine
No, the problem was just less common and things randomly stopped working or crashed instead of getting the warning page.
In theory you can design the browser so it keeps all files open and passes down the handles, but I imagine it's a mess to do that in practice, especially as Firefox is still somewhat configurable.
