DLL- Heap aufräumen oder nicht?
-
+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.
-
edit:
;fricky schrieb:
naja, prinzipientreue ist aber kein <ersatz> für deine grauen zellen, auch wenn manche das glauben.
-
pointercrash() schrieb:
+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?Windows kann das nicht für dich besorgen, da Windows nicht wissen kann, welcher Speicher denn nun freigegeben werden kann.
Kann ja genausogut sein, dass deine DLL Speicher anfordert, einen Zeiger an das Programm übergibt, und das Programm diesen Speicher auch nach Entladen der DLL weiterverwendet.Wenn über DLL und EXE über eine gemeinsame Schnittstelle Speicher anfordern und freigeben (HeapAlloc mit dem Process-Heap oder so), geht das wunderbar. Und ist von Windows aus gesehen vollkommen OK.
Vermutlich wird sowas selten gemacht, aber woher soll Windows wissen, dass nicht gerade deine DLL es macht.Aber sich auf OS rauszureden ist oft die einfachste Möglichkeit
-
pointercrash() schrieb:
... 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?
Diese Formulierung kommt noch aus der Win16 Zeit. Lass dich davon nicht verunsichern. Wenn der Prozess sterben geht, ist er weg. Aus, Ende. Mitsamt allem Speicher den irgendwelche DLLs irgendwann angefordert haben.
Ist allerdings egal, wenn du FreeLibrary unterstützen willst, da du dann trotzdem selbst saubermachen solltest.
