OT4XB / DLLLOAD() und DLLUNLOAD() - Speicher Freigabe ?

[brandelh]

Wer mit der WinAPI andere Datentypen als Parameter benötigt, als Xbase++ standardmäßig anbietet,
sollte sich die OT4XB von Pablo ( http://www.xbwin.com ) ansehen.

In der aktuellen Version ot4xb_001_005_012_021.zip

wurde ein Speicherleck in den Call Routinen aufgedeckt und beseitigt, also dringend updaten !

Dieses Speicherleck wurde im Zusammenhang mit der QuickPDF Bibliothek erkannt.
Pablo hat eine wrapper Klasse geschrieben, die ich nutzen will aber bei vielen Aufrufen ging immer
Speicher verloren. Auch mit der neuen OT4XB - mit PowerBasic trat das Problem nicht auf.
Pablo hat es dann mit C++ getestet und auch dort verschwand bei jedem Aufruf Speicher.
Nach dem Programmende wurde aber immer alles wieder freigegeben.
Eine Einzelanwendung hätte damit leben können, aber ein Serverprogramm ...

Pablo fand dann den Unterschied. Die QuickPDF.DLL belegt bei jedem Laden (DllLOAD()) etwas Speicher
für seine internen Variablen. DllUNLOAD() gibt diesen aber nicht wieder frei (oder die DLL ? ) ...
Im PowerBasic Beispiel wurde die geladene Dll nie entladen und blieb im Speicher bis zum Programmende.

Und genau das ist auch für Xbase++ die Lösung !

Wenn man also nicht genau weiß warum, einfach DllUnload() nicht verwenden.
Eine DLL wird nie zweimal geladen, daher passiert nichts beim nächsten DllLoad() ...

PS: Pablo hat die TQuickPDF für QuickPDF 7.18 freigegeben und meine HB_QPDF (mit einigen eigenen Methoden) folgt bald.

[Tom]

Ich nutze einige Fremd-DLLs, aber mir ist noch keine untergekommen, bei der es Sinn gehabt hätte, sie fallweise zu laden und wieder zu "entladen". Also mache ich das beim Programmstart und sammle die Pointer in einem Array. Dann gibt's auch keine Probleme mit verbleibenden Speicherfragmenten. Um mit List&Label threadsafe umgehen zu können, geschieht es hier zusätzlich für jeden neuen Thread, da prinzipiell parallel gedruckt werden könnte (in der Realität geschieht das allerdings meines Wissens nicht - man müsste schon ganz schön flink sein, um in zwei Threads parallel Druckvorgänge auszulösen).

[brandelh]

Ich nutze einige Fremd-DLLs, aber mir ist noch keine untergekommen, bei der es Sinn gehabt hätte, sie fallweise zu laden und wieder zu "entladen". Also mache ich das beim Programmstart und sammle die Pointer in einem Array. Dann gibt's auch keine Probleme mit verbleibenden Speicherfragmenten.

Warum weiß ich auch nicht, aber irgendwie dachte ich im Destroy meiner Klasse die DLL entladen zu müssen
und Pablo tat es in seiner auch und schon hatten wir den Schlamassel ... daher die Info hier

[Pablo Botella]

Hallo,

wurde ein Speicherleck in den Call Routinen .

.. Fortunatelly dies auftreten, nur in FpQCall() und delegated_FpQCall().
Die Funktionen nFpCall(), ndFpCall() und qwFpCall() hatte diese Probleme nicht.

PS: Pablo hat die TQuickPDF für QuickPDF 7.18 freigegeben und meine HB_QPDF (mit einigen eigenen Methoden) folgt bald.

Meine TQuickPdf war nur als einfachen Wrapper über die QuickPDF-DLL gedacht, die nur zusätzliche ist der Embeded-Unterstützung für binäre Zeichenfolgen (in der gleichen Weise, die auch, die bereitgestellten C++- und C#-Klassen tun). Making auf diese Weise, wenn die QuickPDF-DLL aktualisiert werden wird einfacher, die Wrapper auch aktualisieren.

Aber es gibt eine Menge Verbesserungen, die in der geerbten Klasse, wodurch es einfacher und weitere nützliche getan werden kann.

Ich nutze einige Fremd-DLLs, aber mir ist noch keine untergekommen, bei der es Sinn gehabt hätte, sie fallweise zu laden und wieder zu "entladen".

In der Regel besteht kein Probleme zu laden/eine Dll entladen wenn nur die benötigten Ocasionally und die Dll loslässt, alle Ressourcen auf den Schritt trennen.

Mehrere Lasten der DLL tut nichts, aber der Verweiszähler erhöht, so dass wenn Sie DllLoad() 2 Mal aufrufen die DLL nach Aufruf DllUnload() 2 Mal getrennt werden wird.

Im Fall von QuickPDF einige zugeordneten Ressourcen sind nur aufgegeben, wenn die DLL abgetrennt ist, aus der Proccess, so dass jedes Mal, wenn die QuickPDF-DLL erfolgreich getrennt und wieder an die Proccess angeschlossen ist die verlassenen Ressourcen nicht wiederverwendet werden, aber einen neuen Satz wieder Essen des Speichers zuweisen.

Grüße

Pablo Botella