On Fri, 2011-07-22 at 04:39 +0100, Marko Vojinovic wrote: > On Thursday 21 July 2011 16:51:17 Patrick O'Callaghan wrote: > > Updating the on-disc binary of a running process has no effect on said > > process, it simply creates a new file. New execs of the program will > > execute from that file rather than the old one, but the old one will > > persist until the last running instance of it dies. Of course problems > > can in theory arise if a set of interacting processes are partially > > updated, depending on exactly when each of them executes, but in > > practice I've rarely seen any problems with this (mainly I think because > > apps don't tend to change radically from one version to the next, > > especially in their external interfaces). > > What about this scenario: an app A occasionally loads a library B in order to > use some code from there. Suppose that while A is running (and did not load B > yet because user interaction didn't require it so far) there is an update to > both A and B (which goes to disk). After this happens, the system is in a > potentially inconsistent state --- if a user interacts with A so that A asks > to load B, the *updated* library B will be loaded, which can break A badly, > depending on the difference between old and new B. If A is restarted, > everything will be ok, of course, but until then the *old* A is running from > memory, and loading the new B is a gamble, in general. That could happen but it would depend on how the library is loaded. I'm not sufficiently au fait with the details of Linux dynamic library management to have a well-founded opinion, but AFAIK the loader normally checks that all libraries exist before allowing the process to execute. Whether that means the library files are open or not is another matter. To put it another way: will the process die if the .so file is deleted while it's still running? If it does, then the problem you mention could arise, and if not, not. Testing this is left as an exercise for the reader :-) poc _______________________________________________ kde mailing list kde@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
