我曾经遇到过这个问题几次,并且我无法弄清楚任何解决方案,只能解决这个问题(见下文).
假设一台计算机正在运行2个以上的R实例,由于2个用户或1个用户正在运行多个进程,并且有一个实例在执行update.packages().我有好几次,其他的实例可能会被大肆污染.正在更新的软件包不会以任何影响计算的方式更改功能,但不知何故会出现一个大问题.
简单的解决方案(解决方案0)是在update.packages()执行时终止R的所有实例.这有2个问题.首先,必须终止R实例.其次,人们甚至无法确定这些实例的运行位置(请参阅更新1).
假设正在执行的代码的行为不会改变(例如,包更新都是有益的 - 它们只修复错误,提高速度,减少RAM,并授予独角兽),是否有某种方法可以热插拔新版本的包对其他流程的影响较小？
在R之外我还有两个候选解决方案:
解决方案1是使用临时库路径,然后删除旧的旧库并将新库移动到其位置.这样做的缺点是删除+移动可能会产生一些时间,在此期间没有任何可用的东西.
解决方案2是使用符号链接指向库(或库层次结构),并使用指向更新包所在的新库的指针覆盖符号链接.这似乎导致更少的软件包停机时间 - 操作系统覆盖符号链接所需的时间.这样做的缺点是它在管理符号链接时需要更多的关注,并且是特定于平台的.
我怀疑解决方案#1可以通过巧妙的使用来修改为#2,.libPaths()但这似乎不需要调用update.packages(),而是编写一个新的更新程序,找到过时的包,将它们安装到临时库,然后更新库路径.这样做的好处是,可以将现有流程约束到.libPaths()它启动时的流程(即更改R知道的库路径可能不会传播到那些已经运行的实例,而不在该实例中进行一些明确的干预).
更新1.在示例方案中,两个竞争R实例位于同一台计算机上.这不是必需的:据我了解更新,如果两者共享相同的库,即共享驱动器上的相同目录,则更新仍然可能导致问题,即使R的另一个实例在另一台机器上.因此,人们可能会意外地杀死R进程,甚至看不到它.