Безопасный метод обновления пакетов R - возможна ли «горячая замена»?

Я сталкивался с этой проблемой несколько раз и не могу найти никакого решения, кроме тривиального (см. Ниже ).

Предположим, что на компьютере запущено 2+ экземпляра R из-за того, что 2+ пользователя или 1 пользователь запускают несколько процессов, и один экземпляр выполняет update.packages () . У меня было несколько раз, когда другой экземпляр мог сильно испортиться.Обновляемые пакеты никак не меняют функциональность, влияющую на вычисления, но почему-то возникает большая проблема.

Тривиальное решение (Решение 0) - завершить все экземпляры R во время выполнения update.packages () . У этого есть 2+ проблемы. Во-первых, нужно завершить экземпляры R. Во-вторых, можно даже не определить, где запущены эти экземпляры (см. Обновление 1).

Предполагая, что поведение выполняемого кода не изменится (например, все обновления пакетов полезны - они только исправляют ошибки, повышают скорость, уменьшают объем оперативной памяти и предоставляют единорогов), существует ли способ горячей замены нового версия пакета с меньшим влиянием на другие процессы?

У меня есть еще два возможных решения, помимо R:

Решение 1 - использовать временный путь к библиотеке, а затем удалить старую старую библиотеку и переместить новую в ее место. Недостатком этого является то, что удаление + ходы могут потребовать некоторого времени, в течение которого ничего не будет доступно.

Решение 2 - использовать символические ссылки для указания на библиотеку (или иерархию библиотек) и просто перезаписать символическую ссылку указателем на новую библиотеку, в которой находится обновленный пакет. Похоже, что это влечет за собой еще меньшее время простоя пакета - время, необходимое ОС для перезаписи символической ссылки. Обратной стороной является то, что он требует гораздо большей осторожности при управлении символическими ссылками и зависит от платформы.

Я подозреваю, что решение №1 можно изменить так, чтобы оно было похоже на №2, с помощью умного использования .libPaths () , но похоже, что нужно , а не вызвать ]Обновить.packages () и вместо этого напишет новую программу обновления, которая находит устаревшие пакеты, устанавливает их во временную библиотеку, а затем обновляет пути к библиотекам. Положительным моментом этого является то, что можно ограничить существующий процесс .libPaths () , который он имел при запуске (т.е. изменение путей библиотеки, о которых знает R, может не распространяться на те экземпляры, которые уже запущены, без явного вмешательства в этот экземпляр).

Обновление 1. В примере сценария два конкурирующих экземпляра R находятся на одной машине. Это не требование: насколько я понимаю обновления, если они используют одни и те же библиотеки, то есть одни и те же каталоги на общем диске, то обновление все равно может вызывать проблемы, даже если другой экземпляр R находится на другом компьютере. . Таким образом, можно случайно убить процесс R и даже не увидеть его.