Müssen R-Pakete dynamische Bibliotheken beim Entladen entladen?

Lesezeit: 4 Minuten

Von Hadleys C am besten Praktiken Methoden Ausübungen:

Wie bei C++ sollten Sie immer dann, wenn Sie C-Code in Ihrem Paket verwenden, die DLL entladen, wenn das Paket entladen wird:

.onUnload <- function (libpath) {
  library.dynam.unload("mypackage", libpath)
}

Schreiben von R-Erweiterungen auf der anderen Seite erwähnt dies nicht einmal. Ich kann sehen, wie höflich es wäre, die DLLs zu entladen, aber dies scheint einige seltsame Probleme für mich mit Paketen zu verursachen, die geladen/entladen/neu geladen werden (siehe Beispiel weiter unten). Darüber hinaus gibt es einige Erwähnungen, die darauf hindeuten, dass ein Entladen möglicherweise nicht erforderlich ist. Aus ?library.dynam:

Beachten Sie, dass es betriebssystemabhängig ist, ob es möglich ist, eine DLL zu entladen und dann eine überarbeitete Version derselben Datei neu zu laden: siehe Abschnitt „Wert“ der Hilfe für dyn.unload.

Dies sollte sich jedoch nicht auf Objekte auswirken, die nicht geändert wurden. Dann gibt es diesen Kommentar von Brian Ripley in R-devel:

Meine Erfahrung ist jedoch, dass das Entladen der DLL oft nicht hilft, wenn Sie sie erneut laden müssen (und deshalb entlädt zB tcltk seine DLL nicht).

Ist es also akzeptabel, die C-Bibliotheken geladen zu lassen? Ich würde es vorziehen, nicht nachforschen zu müssen, warum Dinge wie die folgenden passieren (nicht passiert, bevor ich mit dem Entladen von Bibliotheken begonnen habe).

R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin13.1.0 (64-bit)

> library(alike)       # install_github("brodieg/alike", ref="fdaa578e"), if you're curious
> library(data.table)
data.table 1.9.2  For help type: help("data.table")
> detach("package:data.table", unload=T)
> detach("package:alike", unload=T)
> library(alike)
> library(data.table)
Error : .onLoad failed in loadNamespace() for 'data.table', details:
  call: address(x)
  error: object 'Caddress' not found
In addition: Warning messages:
1: In FUN(X[[9L]], ...) :
  failed to assign RegisteredNativeSymbol for alike to alike since alike is already defined in the ‘data.table’ namespace
2: In FUN(X[[9L]], ...) :
  failed to assign RegisteredNativeSymbol for typeof to typeof since typeof is already defined in the ‘data.table’ namespace
3: In FUN(X[[9L]], ...) :
  failed to assign RegisteredNativeSymbol for type_alike to type_alike since type_alike is already defined in the ‘data.table’ namespace
Error: package or namespace load failed for ‘data.table’

Die Warnungen beziehen sich alle auf alike Funktionen. alike nicht verwendet, um seine dynamischen Bibliotheken zu entladen, und die oben genannten Fehler sind nicht aufgetreten. Nachdem ich das Entladen implementiert hatte, traten die Fehler auf. Beachten Sie, dass data.table 1.9.2 hat seine DLLs nicht entladen, obwohl andere Pakete, die ebenfalls keine DLLs entladen, diese Probleme nicht verursacht haben. data.table 1.9.4 funktioniert gut.

  • Ich weiß, es ist Ihre Frage, aber haben Sie überhaupt zusätzliche Informationen dazu gefunden?

    – Dason

    14. April 2015 um 0:08 Uhr

  • @Dason, leider nicht. Ich bin auch reingelaufen dieses Problem mit data.table die zusammenhängen können oder nicht. Außerdem hatte ich dieses Problem seit einiger Zeit nicht mehr, aber es hat sich zu viel geändert, um genau zu wissen, was es behoben hat.

    – BrodieG

    14. April 2015 um 0:29 Uhr

  • Seltsam. Ich habe die Angewohnheit, automatisch zu entladen, weil ich beim Debuggen der falschen Version einer DLL gebissen wurde, die ich vergessen hatte zu entladen. Der Arbeitsablauf war: Paket laden, Fehler finden, beheben, Paket neu laden. Aber die DLL wurde nicht entladen. Ewps. Daher ist Hadleys Rat hervorragend für Entwickler. Aber ich habe noch nie ein Problem wie Ihres in freier Wildbahn gesehen. Interessantes Zeug.

    – Jason

    6. Oktober 2016 um 3:50 Uhr

  • Stellen Sie also die meinungsbasierte Frage „Sollte ich das tun“ oder die themenbezogene Frage „Wie kann ich eine DLL entladen und dann erneut laden, ohne diese Fehler zu erhalten“, auf die die Antwort möglicherweise „nicht “?

    – Nik

    16. März 2017 um 18:36 Uhr

  • Dies scheint irgendwie verwandt zu sein (mögliches Duplikat von?): stackoverflow.com/a/6979989/7411272

    – Hassia Biker

    2. Mai 2017 um 21:53 Uhr

Normalerweise wäre das Entladen einer DLL eine gute Idee. Die Ressourcen, die es besitzt, würden vollständig freigegeben, und das erneute Laden wäre kein Problem.

In R gibt es die Komplikation der R-Umgebung, denn selbst wenn eine DLL entladen wird, kann in der R-Laufzeit etwas Wissen zurückbleiben. In diesem Fall kann das Ergebnis sein, dass die neu geladene DLL-Bibliothek nicht denselben abgeleiteten Zustand wie die R-Variablen hat, die den DLL-Zustand verstehen sollen, und daher Fehler auftreten.

Ich denke, es wäre möglich, ein R-Paket (DLL und R-Code) sicher zu entladen, aber es wäre einfacher für Sie, die DLLs geladen zu lassen, es sei denn, Sie stellen eine besonders starke Ressourcennutzung fest.

  • Ja. Es ist eine sehr schlechte Idee, eine Bibliothek zu entladen, wenn Sie nicht die volle Kontrolle über alle Zeiger auf diese Bibliothek haben. Das Entladen einer Bibliothek ist eine ziemlich ungewöhnliche Operation, und viele Programme rufen FreeLibrary() nie auf. Als Faustregel gilt, dass die Ressourcenzuweisung und -aufhebung in einem externen Paket wie R in der Verantwortung des Pakets selbst liegt sofern nicht ausdrücklich in der Dokumentation angegeben,

    – Michael Roy

    13. Juni 2017 um 13:54 Uhr

1404490cookie-checkMüssen R-Pakete dynamische Bibliotheken beim Entladen entladen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy