错误:已达到最大 DLL 数 [英] Error: Maximal number of DLLs reached

问题描述

我正在编写一个依赖于许多其他包的 R 包.当我在会话中加载太多包时，我经常收到此错误:

I'm writing an R package which depends upon many other packages. When I load too many packages into the session I frequently got this error:

Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/Library/Frameworks/R.framework/Versions/3.2/Resources/library/proxy/libs/proxy.so':
  `maximal number of DLLs reached...

这篇文章超过了 R 中 DLL 的最大数量 指出问题出在基本 R 代码的 Rdynload.c 上:#define MAX_NUM_DLLS 100

This post Exceeded maximum number of DLLs in R pointed out that the issue is with the Rdynload.c of the base R code: #define MAX_NUM_DLLS 100

除了从源代码修改和构建之外，还有什么办法可以绕过这个问题?

Is there any way to bypass this issue except modifying and building from source?

推荐答案

增加这个数字当然是可能的"......但它也有点成本(添加到 R 的固定内存占用).

Increasing that number is of course "possible"... but it also costs a bit (adding to the fixed memory footprint of R).

我没有设置这个限制，但我很确定这也是为了提醒用户在她/他的 R 会话中清理"一点，即不要不必要地加载包命名空间.我还无法想象您需要 > 100 个包裹 |在 R 会话中加载的命名空间.OTOH，现在的一些包有很多依赖项，所以我同意这至少可能比过去更频繁地发生.

I did not set that limit, but I'm pretty sure it was also meant as reminder for the useR to "clean up" a bit in her / his R session, i.e., not load package namespaces unnecessarily. I cannot yet imagine that you need > 100 packages | namespaces loaded in your R session. OTOH, some packages nowadays have a host of dependencies, so I agree that this at least may happen accidentally more frequently than in the past.

当然，真正的解决方案是改进代码，从相对较少的DLLinfo"结构(比如 32)开始，然后根据需要分配更多的批次(比如 32).

The real solution of course would be a code improvement that starts with a relatively small number of "DLLinfo" structures (say 32), and then allocates more batches (of size say 32) if needed.

R 源的补丁(subversion 中的开发主干位于 https://svn.r-project.org/R/trunk/ )非常欢迎！

Patches to the R sources (development trunk in subversion at https://svn.r-project.org/R/trunk/ ) are very welcome!

---- 于 2017 年 1 月 26 日添加:同时，我们有一个 公共错误报告 关于这个，一个提议的补丁(这还不够好:打开文件的数量总是有操作系统相关的限制)，今天该错误报告已关闭由 R 核心成员@TomasKalibera 编写，他实现了新代码，其中加载的 DLL 的最大数量设置为

---- added Jan.26, 2017: In the mean time, we've had a public bug report about this, a proposed patch (which was not good enough: There is always an OS dependent limit on the number of open files), and today that bug report has been closed by R core member @TomasKalibera who implemented new code where the maximal number of loaded DLLs is set at

pmax(100, pmin(1000, 0.6* OS_dependent_getrlimit_or_equivalent()))

在 Windows 和 Linux(尚未测试，但几乎可以肯定"macOS)上，限制应该比以前高很多.

and so on Windows and Linux (and not yet tested, but "almost surely" macOS), the limit should be considerably higher than previously.

----- 更新 #2(写于 2018 年 1 月 5 日):
在 17 年 10 月，通过以下对源代码的提交(仅限 R 的开发版本！)，使上述更改更加自动化.

----- Update #2 (written Jan.5, 2018):
In Oct'17, the above change was made more automatic with the following commit to the sources (of the development version of R - only!)

r73545 |卡利贝拉 |2017-10-12 14:41:20

r73545 | kalibera | 2017-10-12 14:41:20

增加默认情况下可以加载的 DLL 数量.如果需要的话，增加打开文件的软限制.

Increase the number of DLLs that can be loaded by default. If needed, increase the soft limit on open files.

在帮助页面 ?dyn.load (https://stat.ethz.ch/R-manual/R-devel/library/base/html/dynload.html) ulimit -n <现在提到了 num_open_files>(靠近底部的 注意 部分).

and on the help page ?dyn.load (https://stat.ethz.ch/R-manual/R-devel/library/base/html/dynload.html) the ulimit -n <num_open_files> is now mentioned (section Note close to bottom).

所以你可能会考虑使用 R 的开发版本，直到它在 4 月份成为主流".
或者，您可以(在终端/外壳中)

So you might consider using R's development version till that becomes "main stream" in April.
Alternatively, you do (in a terminal / shell)

ulimit -n 2048

ulimit -n 2048

然后从该终端启动 R.Tomas Kalibera 提到这适用于 macOS.

and then start R from that terminal. Tomas Kalibera mentioned this to work on macOS.

这篇关于错误:已达到最大 DLL 数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！