Manuelle Speicherfreigaben bei Programmende
-
Bashar schrieb:
Vor Programmende aufzuräumen ist ungefähr vergleichbar damit, nochmal das Treppenhaus zu fegen bevor die Abrißbirne einschlägt. OK, meine Tante würde das wahrscheinlich machen
Deine Tante ist mir sympathisch.
Ne im Ernst: Das würde ja bedeuten, dass man eine Sonderbehandlung für solche Variablen einführen müsste, die bis zum Programmende existieren. Denn bei allen anderen Variablen muss man sich ja auch darum kümmern, dass sie ordnungsgemäß entsorgt werden. Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.
=> Diese Sonderbehandlung für ganz gewisse Variablen ist auf jeden Fall sehr viel mehr Aufwand, und damit potentiell fehleranfälliger, als einfach jede Ressource ordnungsgemäß zu entsorgen.
-
Konrad Rudolph schrieb:
Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.
doch, macht es.
das OS meldet sogar netzwerkverbindungen bei der gegenstelle ab, wenn dein programm abraucht.
kritisch wird's vielleicht bei nichtflüchtigen sachen wie temporäre dateien und registry-einträge o.ä. die bleiben natürlich erhalten.
-
Der Speicher sollte auf jeden Fall freigegeben werden. Es gibt noch andere Plattformen als BSD, Linux und Windows auf x86ern oder ähnlichem.
Nehmen wir z.B. DSP's. Da gibt es (meistens) kein OS, welches irgendwas hinter einem her räumt. Wohl aber Frameworks, die Prozesse in definierter Reihenfolge abarbeiten. Wenn so ein Prozess, aus welchen Gründen auch immer, terminiert, muss der Speicher freigegeben werden. Gibt noch andere (bessere) Beispiele, auf jeden Fall sollte man sich da nicht auf das OS verlassen.
-
pale dog schrieb:
Konrad Rudolph schrieb:
Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.
doch, macht es.
Ich weiß nicht, ob es ein Bug oder by design ist, aber Windows gibt definitiv nicht immer alle GDI-Handles frei. Ich weiß nicht, auf welche Versionen das zutrifft aber das Verhalten ließ sich recht einfach reproduzieren. Hier musste man wirklich manuell nacharbeiten.
-
Tachyon schrieb:
Der Speicher sollte auf jeden Fall freigegeben werden. Es gibt noch andere Plattformen als BSD, Linux und Windows auf x86ern oder ähnlichem.
Nehmen wir z.B. DSP's. Da gibt es (meistens) kein OS, welches irgendwas hinter einem her räumt. Wohl aber Frameworks, die Prozesse in definierter Reihenfolge abarbeiten. Wenn so ein Prozess, aus welchen Gründen auch immer, terminiert, muss der Speicher freigegeben werden.diese prozesse laufen aber nicht in einer sandbox wie z.b. windows user-mode prozesse. wenn da einer mist baut, dann leidet das ganze system darunter. es reicht ja schon, wenn eine globalen speicherverwaltung benutzt wird und ein prozess regelmässig free oder delete auslässt.
Tachyon schrieb:
Gibt noch andere (bessere) Beispiele, auf jeden Fall sollte man sich da nicht auf das OS verlassen.
ja, die alten windosen wie windoofs 3.11, 95, 98, me.
die waren sowas von schlecht...
Konrad Rudolph schrieb:
Ich weiß nicht, ob es ein Bug oder by design ist, aber Windows gibt definitiv nicht immer alle GDI-Handles frei.
das war bei den alten 16-bittigen wins der fall (siehe oben)
-
pale dog schrieb:
Konrad Rudolph schrieb:
Und andere unverwaltete Ressourcen, also z.B. Grafik-Handles etc. müsste man auch weiterhin selbst freigeben, weil dies das Betriebssystem eben nicht unbedingt übernimmt.
doch, macht es.
das OS meldet sogar netzwerkverbindungen bei der gegenstelle ab, wenn dein programm abraucht....Oho, das würde ich aber nicht so allgemein sagen. Auf unseren AIX-Maschinen mussten wir extra (für die MQ-Verbindung) einen (undokumentierten) keepalive-Parameter setzen - ansonsten schlug ein Standard Timeout von 2 Stunden zu, bevor das kommunzierende System etwas merkte.
Auch die Standard-TCP-Verbindungen hatten untragbare Timeouts (die aber teilweise von anderer Infrastruktur auf der Maschine gefordert wurden) ...Es bleibt dabei: Alle anderen Maßnahmen bedürfen mehr Aufwand an Prüfung, Umsetzung, Testen als ein delete-Statement...
Gruß,
Simon2.
-
Simon2 schrieb:
Oho, das würde ich aber nicht so allgemein sagen. Auf unseren AIX-Maschinen mussten wir extra (für die MQ-Verbindung) einen (undokumentierten) keepalive-Parameter setzen - ansonsten schlug ein Standard Timeout von 2 Stunden zu, bevor das kommunzierende System etwas merkte.
und was sagt uns das? AIX taugt nix!
wieso benutzt ihr undokumentierte parameter? das ist ja erst richtig schlechter stil
btw: ein popeliges windows bekommt es doch auch hin, ein RST zu schicken, wenn das programm abgestürzt ist.
-
pale dog schrieb:
...
wieso benutzt ihr undokumentierte parameter? ...Ganz einfach: Empfehlung vom Hersteller.
Übrigens war es ein Parameter der MQSeries-Software und nicht vom AIX, der da gesetzt werden musste und AIX haben wir nunmal von unserer Firma als Standard aufgedrückt bekommen ... da hilft auch kein Lamentieren (zumal Windowsserver definitiv nicht das geboten hätten, was wir mit den AIX-Servern machen).Ist aber letztlich auch vollkommen egal, weil immer noch nicht klar ist, warum man sich hier von Möglichkeiten/Schwächen/Eigenarten des Betriebssystems abhängig machen sollte, wenn es eine definierte, sichere und unaufwändige Standardtechnik gibt ?
Bislang wurden hier ein Haufen Nachteile und nicht ein Vorteil davon genannt.
Wir können noch 100 weitere Threadseiten mit der Diskussion verbringen, für welche Nachteile es evtl. bei diesem oder jenem OS eine "Umschiffung" gäbe, aber ohne "Aufstockung der Pro-Seite" wird das Fazit dasselbe bleiben...Gruß,
Simon2.
-
Simon2 schrieb:
Ist aber letztlich auch vollkommen egal, weil immer noch nicht klar ist, warum man sich hier von Möglichkeiten/Schwächen/Eigenarten des Betriebssystems abhängig machen sollte, wenn es eine definierte, sichere und unaufwändige Standardtechnik gibt ?
na, ganz einfach: warum dinge doppelt erledigen (stichwort 'abrissbirne')?
aber teilweise gebe ich dir recht: irgendwie muss man sich immer darauf verlassen, dass das eine oder andere funktioniert. redundanz bring auch mehr sicherheit.
-
pale dog schrieb:
...
na, ganz einfach: warum dinge doppelt erledigen (stichwort 'abrissbirne')?...Weil man sich offensichtlich nicht darauf verlassen kann, dass es wirklich jemand an meiner Stelle erledigt (bzw. dass die 'Abrissbirne' exakt den gewünschten Effekt hat wieder 'Staubsauger'
) !
Und "Doppelt gemoppelt" wäre es sowieso nicht, weil das Betriebssystem ja keine bereits abgebauten Ressourcen erneute abbauen würde - das schlägt ja sowieso erst zu, wenn meinem Programm die Kontrolle entglitten ist ...Gruß,
Simon2.