Linked by Thom Holwerda on Wed 15th Jul 2009 16:09 UTC
Linux One of the problem with operating system updates is that you often need to reboot the system. While this is nothing but a minor nuisance for us desktop users, it's a bigger problem when it comes to servers. Ksplice is a technology that allows Linux kernel patches to be applied without actually restarting the kernel.
Thread beginning with comment 373607
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Already in NT.
by cetp on Thu 16th Jul 2009 09:51 UTC in reply to "RE: Already in NT."
Member since:
RE[3]: Already in NT.
by bogomipz on Thu 16th Jul 2009 12:33 in reply to "RE[2]: Already in NT."
bogomipz Member since:

There must be a fundamental difference in how files are handled in Windows and *nix. On a *nix system, when a process reads or writes a file, and this file is deleted, renamed or replaced by another process, the first process will still see the old file until it closes its file handle.

I trust that loading libraries works the same way, although I don't know the details. I guess the trick is that files are considered the same if they are the same inode, regardless of where or when you found them in the file system tree.

Reply Parent Score: 2

RE[4]: Already in NT.
by PlatformAgnostic on Fri 17th Jul 2009 01:20 in reply to "RE[3]: Already in NT."
PlatformAgnostic Member since:

This is true in NT as well. But in UNIX the locking of files is advisory by default and shared by default (i.e. if I open a file anyone else can also open/modify the file and if I say I want to lock it other guys have to check the lock bit in order to respect my wishes). As a design choice (and to increase compatibility with older Windows), NT locking is mandatory and the default (if you specify no flags) is to disallow sharing. The library loader also seems to disallow sharing for delete as well.

As cetp mentions, this may be a conscious design choice because structures shared across process boundaries by DLLs (this can happen via things like Window Messages) may not tolerate having two different versions of the DLL loaded and interacting with each other. There's nothing in the NT Kernel architecture that prevents you from replacing a DLL when the program is still running (you can even do this yourself and get around the file locking problem by just renaming/moving the thing you want to replace and no one will stop you).

Reply Parent Score: 2