On Sat, May 13, 2006 at 10:23:48PM +0300, Tapio Aura Kelloniemi wrote: > Well, perhaps I'm misunderstunding something, but I have assumed > that when a shared library is loaded into memory when a process is > started (or via dlopen) the disk file it comes from is no more read.
My understanding is that the shared library is mmap-ed into the process. This means that the process *thinks* it is just reading memory, but in fact the kernel is reading the file behind the scenes. I think it is possible that the file could be read a long time after the mmap system call finishes. I do know that if I update my Ruby shared library then any Ruby processes running at the time immediately crash, which suggests that writing to a file will write to the address space of any process that mmap-s that file. > After loading the library file may be deleted without affecting the > running process in any way. But if you delete a file from the file system, then the kernel won't really delete the file until *all* references to it have gone. So if a process has an open file handle on that file then the file will persist (even though it's not linked to the file system any more) and the process will be able to read/write the file even though you have "deleted" it. I suspect a similar thing happens if you delete a shared library - if any processes have mmap-ed that library then the kernel will preserve the library and those processes will not notice that the library isn't linked to the file system. If you reinstall the library you will create a new file (even though it has the same path as the old library). New processes will open the path and get the new library, but old processes will continue to access the old library. Anyway, that's how I *think* it works. Regards, Jeremy Henty -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
