Interface aus DLL mit dynamischer Bindung - wann FreeLibrary aufrufen?

[DeddyH]

Ich versuche mich gerade an einer Art Plugin-System. Dabei soll eine DLL ein Interface zurückgeben. Das sieht im Moment so aus:

Delphi-Quellcode:

library Blabla;

uses MyIntf, MyClass; //Units, in denen das Interface und die implementierende Klasse stehen

{$R *.res}

procedure GetDings(out Dings: IDings); stdcall; export;
begin
  Dings := TDings.Create;
end;

exports
  GetDings;

begin
end;

Allerdings soll es mehrere DLLs geben, die verschiedene IDings-Klassen zurückliefern, daher binde ich diese dynamisch (LoadLibrary, GetProcAddress). Klappt soweit, aber der ordentliche Mensch denkt sich: wer LoadLibrary sagt, muss auch FreeLibrary sagen. Bei einem ersten Versuch hat es nur dann keine AV gegeben, wenn ich dies in einen Klassendestruktor verfrachtet habe. Es soll aber auch möglich sein, verschiedene DLLs nacheinander anzusprechen, da würde ich mir auf diese Weise ja jedesmal das Handle überschreiben und könnte somit nur das letzte wieder freigeben. Wo ist denn mein Denkfehler bzw. was könnte ich vergessen haben? Lasse ich FreeLibrary ganz weg, fluppt alles super, aber verschwende ich so keine Ressourcen?

[baumina]

Ich merk mir die Handles in einer Liste, um sie dann mit FreeLibrary freigeben zu können.

[Mavarik]

Übergibt Deiner Interface erzeuge Routine eine Backcall für den FreeLibary

Wenn das Interface Refcount 0 ist, wird der Destructor aufgerufen und der ruft - als letztes - den FreeLib auf.
(Asynchron wegen dem Return auf den Aufrufer)!

[Zacherl]

Resourcen verschwenden würdest du zwar keine, wenn das FreeLibrary sowieso erst bei Beendigung deines Programms aufgerufen würde, aber mit ist es natürlich schon sauberer.

Ohne mehr Code kann ich leider nicht viel sagen, aber ich vermute mal, dass das implizierte _Release von Delphi dir da einen Strich durch die Rechnung macht. Hast du sichergestellt, dass deine Interface-Instanzen vor dem FreeLibrary jeweils einmal manuell auf nil gesetzt wurden? Ansonsten könnte es passieren, dass die DLL entladen wird und danach impliziert _Release (und damit der Destructor) der aus dem Scope-laufenden Objekte gecallt wird. Da zu diesem Zeitpunkt die DLL dann schon entladen ist, gibt es an dieser Stelle die AV.

[DeddyH]

Ich bau mal ein Beispiel.

[DeddyH]

War ja klar: im Beispiel funktioniert alles , der Fehler muss also an einer anderen Stelle liegen. Ich forsche mal weiter.

[Zacherl]

Du könntest meine Theorie relativ einfach testen, indem du im Destructor deiner Objekte (die aus der DLL) mal eine MessageBox einbaust. Dann ersetzt du das FreeLibrary durch eine weitere MessageBox.

Erscheint jetzt die FreeLibrary Message vor der Message aus dem Destructor, weißt du, dass irgendwo noch Objektinstanzen existieren, die vor dem FreeLibrary nicht freigegeben werden.

[DeddyH]

Hab ich gemacht, die Reihenfolge stimmt: zuerst werden die DLL-Objekte freigegeben, danach käme der FreeLibrary-Aufruf. Mittlerweile ist es genau andersherum als eingangs geschildert: wenn ein neuer DLL-Name zugewiesen wird, klappt ein Nullen des alten Objektes mit anschließendem FreeLibrary einwandfrei, nur im Destruktor nicht mehr. Das alles aber nur im echten Projekt, das Referenzbeispiel funktioniert ohne Murren.