3 ms·

> 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'v

> 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.

account42 5y ago
> 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.
- foxfluff 5y ago
  > 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.

account42 5y ago

> 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.

foxfluff 5y ago
> 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.