2 ms·
as far as I know as long as a shared library is loaded you can't just restart every effected service. the os would first need to unload the shared library, thus
by merb 9y ago
as far as I know as long as a shared library is loaded you can't just restart every effected service.
the os would first need to unload the shared library, thus if two services need the same library you need to stop both first and start them again.
thus making the "positive" side of shared libraries basically look very bad on paper. I think that a lot of systems are affected by that problem.
I like shared libraries for a desktop os and applications where you often reboot. But for a server? Hell it's easier to upgrade golang applications/java applications (if the jvm has no bugs and since j9 even bundled) is "saner" to upgrade.
also what a lot of people just don't get is that a sane system mostly only has one service per os/container. thus docker pull vs apt update is basically the same.
- teraflop 9y ago> the os would first need to unload the shared library, thus if two services need the same library you need to stop both first and start them again. No, that's not how it works, at least on Unix systems. Shared libraries are mapped into each process's address space separately; there's no system-wide mechanism that prevents different processes from running different versions of the same library at the same time.
- blattimwind 9y agoIf you try to write a file backing an executable mapping you get ETXTBSY (or not, if it's NFS/some other broken FS). So what everyone is doing is unlink the old file and create a new one. Unlinking preserves open file descriptors, extending to mappings. Note that often the actual backing files are disjunct anyway and only symlinks get replaced, due to versioned .so names (as in libfoo.so.2.4.5, libfoo.so.2.4@, libfoo.so.2@, libfoo.so@, you've all seen it).