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

hustbaer

Mich auch. Ich glaub das nömlich nicht so ganz. Weil halt das Ergebnis meines Versuchs dagegen spricht. Und weil es mMn. sehr viel Aufwand wäre. Da müsste man den Task-Manager schon in den Desktop-Window-Manager einbauen -- und das ist er AFAIK nicht.

SideWinder

Ich wage mich zu erinnern, dass ich das auf Raymond Chans Blog (the old new thing) gelesen habe, kann es aber gerade nicht mehr finden. Da eure empirischen Ergebnisse anders sind, nehme ich die Aussage mal wieder zurück.

Evtl. wars auch nur der Secure Desktop den man mit CTRL+ALT+DEL immer starten kann...

MfG SideWinder

hustbaer

Hab's grad nochmal ausprobiert mit Testlimit.exe -m
Weder der CTRL+ALT+DEL Screen noch der Taskmanager können mehr gestartet werden (Windows 10 x64 1703).

Kann gut sein dass das mit dem CTRL+ALT+DEL Screen in älteren Windows Versionen mal garantiert war, aber aktuell ist es das ganz offensichtlich nicht (mehr).
Gibt sogar ne schöne Fehlermeldung wo steht dass der Screen leider nicht angezeigt werden kann - vielleicht ist jetzt nur mehr Speicher für diese Fehlermeldung reserviert

Ist natürlich schon doof irgendwie. Aber einfach Prozesse wegschiessen finde ich wie gesagt auch nicht gut. Die Variante mit "garantiert dass Task-Manager immer angezeigt werden kann" wäre da schon besser. Bringt aber auch nur was wenn man vor der Box sitzt. Denn per Remote-Desktop braucht man garantiert nicht versuchen sich in so einer Situation noch einzuloggen

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.