错误:已达到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).

我没有设置该限制，但是我很确定，它也可以提醒useR在她/他的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源(在 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日添加:同时，我们有一个

---- 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 | kalibera | 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屋！