Linux vs. Windows (Split aus: Allgemeine Funktion um verfügbaren Speicher zu ermitteln?)

SideWinder schrieb:

für den Task Manager wird unter Windows bereits beim Booten genügend Speicher reserviert. Auch die notwendigen GDI-Handles werden afaik reserviert. Somit sind immer genügend Speicher/Handles verfügbar um den Task Manager zu starten und Prozesse abzuschießen.

Was ich mich während dieser Diskussion auch schon gefragt habe: Wieso kommt das Betriebssystem überhaupt in die Situation, dass Prozesse abgeschossen werden oder gar das ganze System neugestartet werden muss? Wir haben genug Speicher, von dem sich das OS etwas abschneiden kann.

das eigentlich Traurige daran finde ich, dass wir als Programmierer uns so viel Mühe geben um NULL-mallocs und bad_allocs abzufangen und am Ende dann nur SIGTERM kommt

hustbaer

Forkstackerdriver schrieb:

Was ich mich während dieser Diskussion auch schon gefragt habe: Wieso kommt das Betriebssystem überhaupt in die Situation, dass Prozesse abgeschossen werden oder gar das ganze System neugestartet werden muss? Wir haben genug Speicher, von dem sich das OS etwas abschneiden kann.

Das Betriebssystem hat da kein Problem, das läuft eh weiter. Bloss wenn du keine neuen Prozesse mehr starten kannst, weil kein Speicher mehr da ist... dann tut man sich auch schwer bestehende Prozesse zu beenden, damit wieder Speicher frei würde... weil man üblicherweise nicht gerade ein Tool offen hat mit dem man so nen Prozess abschiessen kann.

hustbaer schrieb:

Forkstackerdriver schrieb:

Was ich mich während dieser Diskussion auch schon gefragt habe: Wieso kommt das Betriebssystem überhaupt in die Situation, dass Prozesse abgeschossen werden oder gar das ganze System neugestartet werden muss? Wir haben genug Speicher, von dem sich das OS etwas abschneiden kann.

Das Betriebssystem hat da kein Problem, das läuft eh weiter. Bloss wenn du keine neuen Prozesse mehr starten kannst, weil kein Speicher mehr da ist... dann tut man sich auch schwer bestehende Prozesse zu beenden, damit wieder Speicher frei würde... weil man üblicherweise nicht gerade ein Tool offen hat mit dem man so nen Prozess abschiessen kann.

nach der Logik könnte das OS ja einfach ein Tool offen halten mit dem man den Prozess abschiessen kann

Will aber vor allem nochmal auf meinen anderen Einwand aufmerksam machen: Wieso prüfe ich eigentlich noch den Rückgabewert von malloc()?

Das ist sehr demotivierend.

hustbaer

Ich bin nicht sicher, aber ich würde vermuten dass speziell grosse Allocations auch auf Systemen mit OOM-Killer schief gehen können. Möglicherweise (vermutlich) auch kleine, wenn zu viele kleine Allokationen in zu kurzer Zeit passieren.
Ich vermute dass es beim OOM-Killer eher darum geht dass das System "verwendbar" bleibt bzw. es nach recht kurzer Zeit wieder wird -- und nicht dass jede einzelne Allokation garantiert wird.

Und wenn diese Vermutungen zutreffen, dann heisst das dass du trotzdem den Returnwert von malloc prüfen solltest wenn du willst dass dein Programm in solchen speziellen Situationen nicht trotzdem abkackt.

Wenn du willst kannst du aber natürlich ne eigene malloc Implementierung schreiben die nen Haufen retries macht mit ein bisschen sleep() dazwischen. Und dann nach einer bestimmten Zeit, wenns bis dahin immer noch nicht geklappt hat, einfach abort() aufruft. Dann musst du den Returnwert nicht mehr prüfen

Und natürlich willst du in 32 Bit Prozessen immer den Returnwert von malloc() prüfen.

hustbaer schrieb:

Und wenn diese Vermutungen zutreffen, dann heisst das dass du trotzdem den Returnwert von malloc prüfen solltest wenn du willst dass dein Programm in solchen speziellen Situationen nicht trotzdem abkackt.

Den Rückgabewert von malloc muss man natürlich immer prüfen.
Ich will doch hoffen, das selbst bei 64 bit, malloc(-1) fehlschlägt.

Wenn du willst kannst du aber natürlich ne eigene malloc Implementierung schreiben die nen Haufen retries macht mit ein bisschen sleep() dazwischen. Und dann nach einer bestimmten Zeit, wenns bis dahin immer noch nicht geklappt hat, einfach abort() aufruft. Dann musst du den Returnwert nicht mehr prüfen

oh oh, das klingt ungemütlich. Wenn ich C programmiere, sieht meine malloc Implementierung in pseudo-code so aus:

void* xmalloc (size_t n) {return malloc(n) or abort ("malloc failed");}

(abgeguckt von git und anderen)

In C++ ignoriere ich einfach bad_alloc() und wünsche mir, dass niemand jemals catch(std::exception) oder catch(...) macht.
Das ganze bad_alloc()-exception-Konzept ist IMHO für den Eimer.