DLL- Heap aufräumen oder nicht?
-
+gjm+ schrieb:
pointercrash() schrieb:
Win macht ja den ganzen Speicherkontext der DLL beim Entladen weg ...
Das bezieht sich nur auf den Speicher, der unmittelbar mit dem Laden und Entladen einer DLL gebraucht wird.
Allen Gerüchten zum Trotze verfügt das Betriebssystem über keinen eingebauten GC.Was? Echt so schlimm? Mit einem GC hat das nix zu tun,
MSDN schrieb:
or the process terminates, the system unloads the module from the address space of the process. Before unloading a library module, the system enables the module to detach from the process by calling the module's DllMain function, if it has one, with the DLL_PROCESS_DETACH value. Doing so gives the library module an opportunity to clean up resources allocated on behalf of the current process. After the entry-point function returns, the library module is removed from the address space of the current process.
... aber "resources allocated on behalf of the current process" versteh' ich jetzt einfach nicht. Dann wär' das ja jenseits jeden Witzes, wenn es keinen lokalen Heap gäbe, der nur im Kontext der DLL existieren würde.
Also bliebe der Speicher im Heap auch nach unload der DLL reserviert - wofür?
-
berniebutt schrieb:
Wozu soll sonst DllMain dienen, wenn nicht auch zum Aufräumen? daddeldu
Ich habe keine Ahnung, deswegen frage ich ja euch. Ich bin nur etwas verblüfft, daß man einem OS heute noch den Hintern manuell auswischen muß. Ich dachte, daß sich win seit NT selbst von vollgekackten Windeln freimachen kann.
-
pointercrash() schrieb:
... aber "resources allocated on behalf of the current process" versteh' ich jetzt einfach nicht.
Grob übersetzt heißt das wirklich, daß die DLL ihre vollgekackten Windeln gefälligst selbst "beseitigen" soll.
pointercrash() schrieb:
Dann wär' das ja jenseits jeden Witzes, wenn es keinen lokalen Heap gäbe, der nur im Kontext der DLL existieren würde.
Das OS unterscheidet nicht mehr zwischen "lokalem" oder "globalem" Heap. Eine Unterscheidung hätte auch erhebliche Nachteile für ein effizientes Speichermanagement. Allerdings kann man globale Variablen in der DLL als "lokalen" Heap betrachten (ist aber nicht zu empfehlen).
pointercrash() schrieb:
Ich bin nur etwas verblüfft, daß man einem OS heute noch den Hintern manuell auswischen muß.
Nun, der Fortschritt besteht schon mal darin, daß man LoadLibrary () nicht auch noch mit einem "Handle" zum Speicher aufrufen muß (der dann hinterher auch wieder freigegeben werden muß). Ich persönlich fände es eher erschreckend wenn ein OS auf das Byte genau weiß, wieviel Speicher eine DLL/EXE benötigen wird. Und zwar vor dem laden schon.
-
+gjm+ schrieb:
Ich persönlich fände es eher erschreckend wenn ein OS auf das Byte genau weiß, wieviel Speicher eine DLL/EXE benötigen wird. Und zwar vor dem laden schon.
Mich persönlich schockiert eher, daß Win nicht weiß, was es mit dem Entladen einer DLL alles aus dem Speicher kippen kann.
Mich verunsichert volkards Eintrag zusätzlich, nachdem ich gar nix machen müßte - aber was soll's?Also gut, die Tables werden explizit gekillt - ob das aber wirklich nötig ist, interessiert mich natürlich weiterhin.
-
pointercrash() schrieb:
Mich verunsichert volkards Eintrag zusätzlich, nachdem ich gar nix machen müßte - aber was soll's?
Kam falsch rüber. Ich wollte eine Klarstellung bekommen, ob es nur guter Stil ist oder ob es echt notwendig ist.
-
nimm nicht malloc/free, sondern z.b. diese funktionen: http://msdn.microsoft.com/en-us/library/aa366781(VS.85).aspx#heap_functions
dann noch bei DLL_PROCESS_ATTACH und DLL_PROCESS_DETACH einen zähler mitlaufen lassen. geht er von 0 auf 1 (erster prozess connected sich mit der dll) dann mit HeapCreate() den heap erzeugen und wenn er von 1 auf 0 geht (alle prozesse weg), dann mit HeapDestroy() den heap wegschmeissen. nur vom prinzip her, könnte klappen. oder du macht es mit VirtualAlloc/VirtualFree.
-
volkard schrieb:
pointercrash() schrieb:
Mich verunsichert volkards Eintrag zusätzlich, nachdem ich gar nix machen müßte - aber was soll's?
Kam falsch rüber. Ich wollte eine Klarstellung bekommen, ob es nur guter Stil ist oder ob es echt notwendig ist.
Nein, es ist selbstverständlich absolut nicht notwendig.
Ist wie mit dem Geschirr, wenns dreckig ist und Du genug davon hast, kannst Du es auch einfach ungewaschen auf dem Tisch stehen lassen und hoffen, dass die Hausverwaltung spätestens bei deinem Auszug aufräumt.Ich persönlich mache es nicht so.
Ich weiss nicht, ich finds ziemlich simpel: Alles was ich anfordere an Resourcen (Speicher, File Handles, etc.) gebe ich dann zurück wenn ich es nicht mehr benötige.
Simon
-
pointercrash() schrieb:
Also gut, die Tables werden explizit gekillt
-
pointercrash() schrieb:
Mich persönlich schockiert eher, daß Win nicht weiß, was es mit dem Entladen einer DLL alles aus dem Speicher kippen kann.
Der Heap, auf dem Du Deine Tabellen allokiert hast, ist eine Ressource des Prozesses. Und dieser Heap lebt bis zum Ende eben dieses Prozesses (wenn Du ihn zuvor nicht selber killst).
Es wird nicht Buch darüber geführt, aus welchem Modul die allocs kamen. Und das ist auch gut so (weil's Rechenzeit und Platz braucht).
Wenn Du es einfach haben willst, erstellst Du Dir Deinen eigenen Heap (HeapCreate). In DllMain kannst Du dann ganz einfach HeapDestroy aufrufen -> dann verschwindet auch alles das, was Du per HeapAlloc angefordert hast (Du sparst Dir damit die einzelnen HeapFrees).
-
Mox schrieb:
Es wird nicht Buch darüber geführt, aus welchem Modul die allocs kamen. Und das ist auch gut so (weil's Rechenzeit und Platz braucht).
Das ist vor allem deshalb gut so, weil ich den Speicher theoretisch im Prozess weiterverwenden kann, auch wenn die DLL explizit entladen wird.
-
theta schrieb:
... ich finds ziemlich simpel: Alles was ich anfordere an Resourcen (Speicher, File Handles, etc.) gebe ich dann zurück wenn ich es nicht mehr benötige.
Das ist und bleibt guter Programmierstil, selbst wenn das System mit einigem alleine aufräumt!
-
berniebutt schrieb:
theta schrieb:
... ich finds ziemlich simpel: Alles was ich anfordere an Resourcen (Speicher, File Handles, etc.) gebe ich dann zurück wenn ich es nicht mehr benötige.
Das ist und bleibt guter Programmierstil, selbst wenn das System mit einigem alleine aufräumt!
100% Ack.
-
berniebutt schrieb:
theta schrieb:
... ich finds ziemlich simpel: Alles was ich anfordere an Resourcen (Speicher, File Handles, etc.) gebe ich dann zurück wenn ich es nicht mehr benötige.
Das ist und bleibt guter Programmierstil, selbst wenn das System mit einigem alleine aufräumt!
Naja, ich hab' ja geschrieben, wo das Zeug herkommt, nämlich vom Controller und da störts nicht, wenns aufm Heap liegenbleibt, im Gegenteil, zwei der Tables werden noch benötigt.
Im Allgemeinen ist es ja keine Frage des guten Stils, ob ich mir die Schläfe desinfiziere, bevor ich mir eine Kugel durch die Birne jage - das ist eher bizarr.
Ein Teil der Funktionalität soll jedoch unter Win laufen und weil ich nicht gleich die Source hergeben mag, packe ich's in eine DLL und muß halt die Spielregeln von Win beachten.
Also, da ich die Codebasis behalten möchte und mit HeapCreate dann auch alles auf HeapAlloc usw. umbiegen müßte, würde das zu einem heftigen #ifdef- Dschungel führen, dafür wäre nach HeapDestroy() die Landschaft wieder sauber.
Wenn ich bei malloc/free bleibe, sollte ich hingegen selbst aufräumen - hab' ich das richtig verstanden?
Hab' mich mal wegen Tippfaulheit für zweiteres entschieden und jetzt drei Funktionen, die die DLL exportiert, ein Initialisierungsaufruf, der das Teil parametriert (und auch die Tabellen aufbaut), einen Aufruf zur Konvertierung und einen, der die Tabellen wieder abreißt.
Ist damit den Win- Konventionen genüge getan?
-
Ich bin so, ich würde auch auf dem kleinsten Micro Dingsbums das zeugs wieder freigeben, wenn ichs angefordert habe...
-
theta schrieb:
Ich bin so, ich würde auch auf dem kleinsten Micro Dingsbums das zeugs wieder freigeben, wenn ichs angefordert habe...
Es gibt Fälle, in denen es nicht nur grund- und sinnlos ist, sondern kontraproduktiv.
Du rückst das in die Nähe einer Zwangshandlung, aber ich versichere Dir, man darf darüber wirklich nachdenken, deswegen frage ich ja hier nach.
Aber was soll's, Monk ist ja auch ganz lustig ...
-
pointercrash() schrieb:
Es gibt Fälle, in denen es nicht nur grund- und sinnlos ist, sondern kontraproduktiv.
... Zwangshandlung, aber ich versichere Dir, man darf darüber wirklich nachdenken, deswegen frage ich ja hier nach.Wann und wo?
Willst Du beim Programmieren selbst die Kontrolle behalten oder willst Du auf ein Dir unbekanntes Systemverhalten vertrauen?
Stellst Du Dein Auto mit laufendem Motor in die Garage in der Erwartung, wenn man das Garagentor zumacht geht der Motor schon aus?
Die Kugel kannst Du Dir auch so in die Birne jagen...
Dann brauchen wir hier nicht weiter über Dein Anliegen nachzudenken...
-
berniebutt schrieb:
pointercrash() schrieb:
Es gibt Fälle, in denen es nicht nur grund- und sinnlos ist, sondern kontraproduktiv.
... Zwangshandlung, aber ich versichere Dir, man darf darüber wirklich nachdenken, deswegen frage ich ja hier nach.Wann und wo?
Willst Du beim Programmieren selbst die Kontrolle behalten oder willst Du auf ein Dir unbekanntes Systemverhalten vertrauen?
Stellst Du Dein Auto mit laufendem Motor in die Garage in der Erwartung, wenn man das Garagentor zumacht geht der Motor schon aus?Wenn ich fertig mit Fahren bin, halte ich vermittels der Bremse einfach an, und der Motor geht ganz von alleine aus. Aber es gibt Leute, die mir vorschreiben wollen, daß ich zuerst bei laufendem Motor ausgekuppelt anhalten soll, dann die Zündung unterbrechen soll und dann wieder einkuppeln. Wozu?
-
Wenn garantiert ist, daß
(1) die DLL nur einmal geladen wird und
(2) die DLL frühestens bei Prozessende "entladen" wird,dann ist das ständige Auf- und wieder Abbauen der (wiederverwendbaren) Tabellen in der Tat eine chronische Zwangshandlung.
-
Wenn der Inhalt der Tabellen sowieso immer der Selbe ist und bleibt, stehen doch bereits zum Zeitpunkt des Compilierens alle Informationen fest. Wozu muss dann überhaupt noch der Umweg über alloc gegangen werden?
-
berniebutt schrieb:
Willst Du beim Programmieren selbst die Kontrolle behalten oder willst Du auf ein Dir unbekanntes Systemverhalten vertrauen?
das ist kein unbekanntes verhalten. windoof macht alle handles eines prozesses zu, wenn er beendet wird (wie auch immer das geschieht, normal oder durch absturz). dazu gehört z.b. dass files geschlossen, speicher freigegeben und sogar TCP-verbindungen gekillt werden (es wird ein RST an die gegenstelle geschickt).
berniebutt schrieb:
Stellst Du Dein Auto mit laufendem Motor in die Garage in der Erwartung, wenn man das Garagentor zumacht geht der Motor schon aus?
naja, prinzipientreue ist aber kein für deine grauen zellen, auch wenn manche das glauben.