Ich habe dieses Problem ein paar Mal erlebt und bin nicht in der Lage, eine Lösung zu finden, außer der trivialen (siehe unten).
Angenommen, auf einem Computer werden mehr als zwei Instanzen von R ausgeführt, weil entweder mehr als zwei Benutzer oder ein Benutzer mehrere Prozesse ausführt und eine Instanz update.packages() ausführt. Ich hatte mehrere Male, wo die andere Instanz große Zeit vermasseln kann. Die Pakete, die aktualisiert werden, ändern die Funktionalität in keiner Weise, die sich auf die Berechnung auswirkt, aber irgendwie entsteht ein großes Problem.
Die triviale Lösung (Lösung 0) besteht darin, alle Instanzen von R zu beenden, während update.packages() ausgeführt wird. Dies hat 2+ Probleme. Zuerst muss man R-Instanzen beenden. Zweitens kann man möglicherweise nicht einmal feststellen, wo diese Instanzen laufen (siehe Update 1).
Unter der Annahme, dass sich das Verhalten des ausgeführten Codes nicht ändert (z. B. Paket-Updates sind alle vorteilhaft - sie beheben nur Fehler, verbessern die Geschwindigkeit, reduzieren RAM und gewähren Unicorns), gibt es eine Möglichkeit, einen neuen Hot-Swap auszutauschen Version des Pakets mit weniger Auswirkungen auf andere Prozesse?
Ich habe zwei weitere Kandidatenlösungen außerhalb von R:
Lösung 1 besteht darin, einen temporären Bibliothekspfad zu verwenden und dann die alte alte Bibliothek zu löschen und die neue an ihren Platz zu verschieben. Der Nachteil davon ist, dass Löschungen + Bewegungen einige Zeit dauern können, während denen nichts verfügbar ist.
Lösung 2 besteht darin, mit symbolischen Links auf eine Bibliothek (oder eine Bibliothekshierarchie) zu verweisen und einen symbolischen Link einfach mit einem Zeiger auf eine neue Bibliothek zu überschreiben, in der sich das aktualisierte Paket befindet. Dies scheint noch weniger Paketausfallzeiten zu verursachen - die Zeit, die das Betriebssystem benötigt, um einen Symlink zu überschreiben. Der Nachteil davon ist, dass es viel mehr Sorgfalt bei der Verwaltung von Symlinks erfordert und plattformspezifisch ist.
Ich vermute, dass Lösung # 1 wie # 2 geändert werden kann, indem man .libPaths() geschickt einsetzt, aber das scheint so zu sein, als müsste man nicht update.packages() aufrufen und stattdessen ein neues schreiben Updater, der die veralteten Pakete findet, sie in einer temporären Bibliothek installiert und dann die Bibliothekspfade aktualisiert. Der Vorteil dabei ist, dass man einen vorhandenen Prozess auf das .libPaths() beschränken kann, wenn er gestartet wurde (dh das Ändern der Bibliothekspfade, von denen R weiß, wird möglicherweise nicht auf die bereits laufenden Instanzen propagiert, ohne dass ein expliziter Eingriff in diese Instanz erfolgt ).
Update 1. Im Beispielszenario befinden sich die beiden konkurrierenden R-Instanzen auf demselben Rechner. Dies ist keine Voraussetzung: Soweit die beiden Versionen die gleichen Bibliotheken verwenden, dh dieselben Verzeichnisse auf einem freigegebenen Laufwerk, kann das Update weiterhin Probleme verursachen, selbst wenn sich die andere Instanz von R auf einem anderen Computer befindet . Man könnte also einen R-Prozess versehentlich beenden und nicht einmal sehen.
Meine starke Vermutung ist, dass es keinen Weg gibt.
Insbesondere wenn ein Paket kompilierten Code enthält, können Sie die DLL nicht entfernen und ersetzen, während sie verwendet wird, und erwarten, dass sie weiterhin funktioniert. Alle Zeiger in der DLL, die von R-Aufrufen dieser Funktionen verwendet werden, werden nach einem bestimmten Speicherort fragen und finden es unerklärlicherweise verschwunden. (Hinweis - während ich hier den Begriff "DLL" verwende, meine ich das in einem nicht Windows-spezifischen Sinne, wie er zB in der Hilfedatei für ?getLoadedDLLs verwendet wird. "Shared Library" ist vielleicht der bessere Oberbegriff.)
(Einige Bestätigungen meines Verdachts kommen von der R für Windows FAQ , die meldet, dass "Windows die DLL des [a] Pakets während des Ladens sperrt", was dazu führen kann, dass update.packages() fehlschlägt.)
Ich bin mir nicht sicher, wie genau der Lazy-Load-Mechanismus von R implementiert ist, aber stellen Sie sich vor, dass es auch durch das Entfernen von Objekten, die es an bestimmten Adressen in der Maschine zu finden versucht, durcheinander gebracht werden könnte.
Jemand, der mehr über die Interna von Computern weiß, wird sicherlich eine bessere Antwort geben als dies, aber das sind meine Gedanken.
In einer Produktionsumgebung möchten Sie wahrscheinlich mindestens zwei Versionen behalten, die aktuelle und die vorherige, um im Falle eines Problems schnell zu der alten Version wechseln zu können. Nichts würde überschrieben oder gelöscht werden. Es ist einfacher, dies für das gesamte R-Ökosystem zu tun: Sie hätten mehrere Verzeichnisse, sagen "R-2.14.1-2011-12-22", "R-2.14.1-2012-01-27" usw., jedes enthält alles (die ausführbaren R-Dateien und alle Pakete). Diese Verzeichnisse werden niemals aktualisiert: Wenn ein Update benötigt wird, wird ein neues Verzeichnis erstellt. (Einige Dateisysteme stellen "Snapshots" bereit, mit denen Sie viele sehr ähnliche Verzeichnisse ohne übermäßigen Speicherplatz verwenden können.)
Der Wechsel von einer Version zur anderen kann auf der Benutzerseite erfolgen, wenn Benutzer R starten, indem sie entweder die ausführbare Datei R durch ein Skript ersetzen, das die korrekte Version verwendet, oder indem sie ihre Umgebungsvariable PATH so einstellen, dass sie auf die gewünschte Version. Dies stellt sicher, dass eine gegebene Sitzung immer die gleiche Version von allem sieht.
Hier ist ein Szenario, dem ich gestern bei Windows 7 begegnet bin.
Die Installation schlägt natürlich fehl, da Windows das PDF immer noch geöffnet hat und nicht überschreiben kann.