4. "exit()" in einer lib?!

"exit()" in einer lib?!

  • ?

    knivil schrieb:

    kümmert sich ja exit() auch darum, dass allokierter speicher freigegeben wird, file-handles geschlossen werden usw.

    Das macht das Betriebssystem.

    Nein. Wenn ich einfach Speicherplatz allokiere und dann das Programm beende, führt das zu Memory-Leaks...

    Mag sein, dass das Betriebssystem den RAM-Speicher überwacht, damit kein Speicherplatz einfach so überschrieben werden kann, aber das Betriebssystem freed garnix.

    0
  • ?

    exit(0x123); schrieb:

    knivil schrieb:

    kümmert sich ja exit() auch darum, dass allokierter speicher freigegeben wird, file-handles geschlossen werden usw.

    Das macht das Betriebssystem.

    Nein. Wenn ich einfach Speicherplatz allokiere und dann das Programm beende, führt das zu Memory-Leaks...

    Mag sein, dass das Betriebssystem den RAM-Speicher überwacht, damit kein Speicherplatz einfach so überschrieben werden kann, aber das Betriebssystem freed garnix.

    Genau Null Ahnung du hast, digg0r.

    0
  • ?

    Ok, klär mich auf was diesen Punkt betrifft.

    Und hör endlich mit diesem peinlichen "diggr" auf.

    Also so hab ich das gelernt:
    Der gesamte RAM wird in gleich große Stücke aufgeteilt, so 4KB usw. Irgendwo im Betriebssystem gibt es ein (char-)Array, das genau GrößeDesRams/4KB - Teile hat.

    Wenn nun ein Programm Speicherplatz alloziert wird, wird eine bestimmte Stelle in dem Array auf 1 gesetzt (bzw. sonstig markiert), das bedeutet, dass dieser Speicherplatz gerade benutzt wird und auf keine Fall einem anderen Programm zugwiesen werden darf.

    Wenn ich nun free() aufrufe, wird in das Array wieder 0 eingetragen, d.h. der Speicherplatz ist freigegeben und darf neu beschrieben werden.

    Wenn ich (der Programmierer!) kein free() aufrufe, dann wird der Speicherplatz auch nicht freigegeben (dies geschieht dann nach einem Neustart, wenn wieder alle Array-Elemente auf 0 sind).

    z.b.
    Ich habe 4 GB-RAM (=4194304 KB), dann könnte das so aussehen

    #define ARRAY_SIZE (4194304/4) // die Größe des Rams in KB durch 4 KB
char memory[ARRAY_SIZE];

// jetzt werden die ersten 4 KB allokiert:
memory[0]=1; // erstes 4kb-großes segment ist belegt und darf nicht durch andere programme benutzt werden.

    Das ist natürlich stark vereinfacht, aber so in etwa gehts.

    0

  • ...

    0
  • ?

    Swordfish schrieb:

    Moi, süß! 🙂

    Achso... ja das erklärt natürlich alles 🙄

    wenn ihr keine lust habt, euch hier an gescheiten gesprächen zu beteiligen, dann lasst es doch einfach!

    0
  • ?

    Geil wie er nicht auf digga klarkommt :p

    0
  • Mod

    Das Betriebssystem (wenn's nicht gerade aus den 70er Jahren ist oder auf einem Mikorcontroller läuft) weiß aber, welcher Prozess welche Speicherseiten belegt hat und welche Dateien er offen hält. Wenn der Prozess beendet wird, kann (und wird) daher alles sauber freigegeben.

    Trotzdem ist das gute Praxis, auch im Fehlerfall sauber aufzuräumen.

    Es sind auch Ressourcen denkbar, von denen das Betriebsystem nichts weiß (weil es nicht direkt damit zu tun hat), die auch freigegeben werden müssen. Bei allen Arten von Ressourcen kann man dann die gleichen Programmmuster benutzen, um eine saubere Freigabe zu garantieren.

    0
  • ?

    exit(0x123); schrieb:

    Und hör endlich mit diesem peinlichen "diggr" auf.

    ey oldär, exit(0x0815) ist aber nicht peinlich oda watt?
    🙄

    0
  • ?

    digga++ gemobbt schrieb:

    ey oldär, exit(0x0815) ist aber nicht peinlich oda watt? 🙄

    Nicht annähernd so peinlich wie "ey oldär," "digg0r" und "lolz0r." Du klingst wie die Karikatur eines Skriptkiddies aus einem Gamer-Forum. Lass das.

    Was den eigentlichen Thread angeht: alles, was auf Betriebssystemebene mit einem einzelnen Prozess (und nur diesem) zusammenhängt, wird bei Prozessende eingerissen, davon kann man ausgehen. Dazu zählt der Freestore (Heap) und die relevanten Teile der Page Table, offene Dateideskriptoren und derlei Dinge mehr, die nach Prozessende stumpf keinerlei Bedeutung mehr haben. Die Information, was Filehandle 16 in Prozess 1234 mal war, ist nach dessen Ende schlicht von niemandem mehr verwendbar. Ob allerdings die Daten im zugehörigen Buffer noch auf die Platte geschrieben werden, ist eine andere Frage; wenn der Prozess hart runtergeht, kann so was von System zu System verschieden sein.

    Es gibt allerdings Dinge, die auf Betriebssystemebene nicht eindeutig einem Prozess zuzuordnen sind, und diese werden dann auch nicht aufgeräumt. Dazu zählen beispielsweise temporäre Dateien, Kindprozesse, shared memory und Dinge, die dein Programm in anderen Prozessen ausgelöst haben mag. Wenn du beispielsweise eine Netzwerkverbindung zu einem Server hältst und dein Prozess einfach abschmiert, wird diese Verbindung auf der Gegenseite noch eine Weile offen bleiben (bis zum Timeout). Im Umgang mit solchen Dingen ist dann auch entsprechende Vor- und Umsicht angebracht -- und da du als Bibliothek darauf vorbereitet sein musst, in Programmen benutzt zu werden, die mit derlei Dingen umgehen, ist ein harter Abbruch per Design da nicht sinnvoll.

    Wenn du einmal undefiniertes Verhalten ausgelöst hast und feststellst, dass der Zustand des Programms hoffnungslos zerschossen ist, dann macht eine Notbremse die Sache auch nicht mehr schlimmer, aber gelöst werden muss das Problem natürlich, indem kein undefiniertes Verhalten mehr ausgelöst wird -- also per Bugfix.

    0
  • ?

    seldon schrieb:

    Nicht annähernd so peinlich wie "ey oldär," "digg0r" und "lolz0r." Du klingst wie die Karikatur eines Skriptkiddies aus einem Gamer-Forum. Lass das.

    yo. amen, mann.

    0
Anmelden zum Antworten