Wird ein Programm sauber beendet wenn man das Konsolenfenster schließt?
-
Der Titel sagts eigentlich schon, angenommen da wird gerad etwas langes berechnet und am Ende sollen 10 Objekte gelöscht werden und der Anwender klickt auf das Kreuz zum Beenden des Konsolenfensters (oder irgendwo wird exit(0) aufgerufen) werden diese Objekte dann freigegeben?
Ich denke nicht, was kann man da tun?
-
Windows (ich gehe jetzt mal von diesem System aus, wird aber bei Unix u.a. auch so sein) weiß ja wieviel Speicher die Anwendung benötigt hat. Beim Schliessen der Anwendung (egal wie!) wird der Speicher einfach frei gegeben. Kannst du ja im Taskmanager beobachten!
Was natürlich nicht passiert, ist das alle Dekonstruktoren deiner Objekte aufgerufen werden. Aber solange keine Daten auf Platte geschrieben werden ist das furz egal.
-
und wenn ich z.b. dynamisch mit new speicher reserviere? musst das delete nicht ausgeführt werden?
-
Müsste schon, nur gibt das OS beim Programmende (egal wie) den _gesamten_ von deinem Prozess verwendeten Speicher frei.
Tja, das kann sogar Microoft Windows.
[OffTopic]
Fällt mir grad so ein: (Word is mir grad vom OS beendet worden...)
If Microsoft Word was intended to be used for something longer than
a word it would have been named 'MS Sentence', 'MS Paragraph' or 'MS Book'.[/OffTopic]
-
Das Problem bei der automatischen Speicherfreigabe durch das Sytem ist aber, dass keine Destruktoren aufgerufen werden. Wenn du also in einem Objekt resourcen (altertümlicher marker in Form einer Datei ist ein harmloses Beispiel) allokiert hast, werden die nicht freigegeben. Unter Linux/Unix werden einem Prozess zunächst 2 Signale (eins zum warnen, das zweite kann man nicht abfangen) geschickt. Wenn ich mich recht erinnere, werden einem Windows-programm Nachrichten geschick.
-
ness schrieb:
Das Problem bei der automatischen Speicherfreigabe durch das Sytem ist aber, dass keine Destruktoren aufgerufen werden. Wenn du also in einem Objekt resourcen (altertümlicher marker in Form einer Datei ist ein harmloses Beispiel) allokiert hast, werden die nicht freigegeben.
naja, für das os ist ein user-programm wie jedes andere. es weiss nichts davon, dass man es mit einer programmiersprache geschrieben hat, die 'destruktoren' anbietet, also kann es diese auch nicht aufrufen. es gibt da so sachen wie 'atexit()' aber das wird (unter windoof) auch nicht aufgerufen, wenn die anwendung auf die harte tour gekillt wurde.
...und zu den files: unter win werden alle dateien geschlossen (vorher der cache 'geflushed'), alle file handles beseitigt etc. so dass normalerweise nicht viel kaputt gehen kann.
-
Unter Windows werden alle Locks, Handles, etc. die eine Anwendung hält, sauber geschlossen.
Unter Unix gibt es ein paar Locks, die nicht automatisch freigegeben werden (müssen). Insbesondere Mutex-Locks werden beim harten Beenden (oder man vergisst es einfach) nicht freigegeben. Führt dazu, dass irgendwann alle Deskriptoren weg sind und man rebooten darf. Ist aber alles stark systemabhängig - eine pauschalisierte Aussage was wann wo wie freigegeben wird, ist ohne weiteres nicht möglich.
-
Harry Hirsch schrieb:
Unter Unix gibt es ein paar Locks, die nicht automatisch freigegeben werden (müssen). Insbesondere Mutex-Locks werden beim harten Beenden (oder man vergisst es einfach) nicht freigegeben. Führt dazu, dass irgendwann alle Deskriptoren weg sind und man rebooten darf.
Man muss nicht rebooten, es gibt ein paar Befehle, mit denen man die System-V-IPC-Handles von der Kommandozeile aus verwalten kann.
-
@Bashar:
Hast Du dazu gerade eine Kurzreferenz parat? Das wäre sehr hilfreich.
Und wie siehts mit Posix-Locks aus? Die müssen ja nicht zwangsweise auf System-V-Locks abgebildet werden.
-
@net: mein Beispiel bezog sich mehr auf einen altertümlichen Marker durch die Datei selbst, nicht durch deren Inhalt...
-
Harry Hirsch schrieb:
Unter Windows werden alle Locks, Handles, etc. die eine Anwendung hält, sauber geschlossen.
Da hab ich aber andere Erfahrung. Locken von Files kann bleiben. Ganz sicher bin ich bei Win98. Würde bei WinXP kein anderes Veralten vermuten.
Vielleicht sollte man noch erwähnen, daß man (bei win und linux) einen Handler absetzen kann, der in alter C-Manier aufräumt. Mir ein wenig Zauberei kann man daraus auch ein C++-Programm für die Konsole stricken, das alle Destruktoren aufruft.
-
ness schrieb:
@net: mein Beispiel bezog sich mehr auf einen altertümlichen Marker durch die Datei selbst, nicht durch deren Inhalt...
klar, dein 'altertümlicher marker' bleibt so.
btw: es gibt ein paar blöde dlls, die irgendwelche variablen in shared memory halten (damit die prozessübergreifend sichtbar sind). wenn man so einen prozess killt, dann hat der keine chance mehr was dran zu verändern. also wenn man pech hat, muss man sich ausloggen und wieder einloggen, damit alles so funzt wie gewohnt. ich glaub' die position von messageboxen ist so'n kandidat. da bemerkt win erst ziemlich spät, dass es die wieder zurücksetzen soll
-
Harry Hirsch schrieb:
Unter Windows werden alle Locks, Handles, etc. die eine Anwendung hält, sauber geschlossen.
Unter Unix gibt es ein paar Locks, die nicht automatisch freigegeben werden (müssen). Insbesondere Mutex-Locks werden beim harten Beenden (oder man vergisst es einfach) nicht freigegeben. Führt dazu, dass irgendwann alle Deskriptoren weg sind und man rebooten darf. Ist aber alles stark systemabhängig - eine pauschalisierte Aussage was wann wo wie freigegeben wird, ist ohne weiteres nicht möglich.
Wenn du mit Mutex-Locks, die Dinger meinst, die mit pthread_mutex_lock verwaltet werden, dann ist es auch bei denen so, dass sie nach einem kill zurückgesetzt werden.
-
Ponto schrieb:
Wenn du mit Mutex-Locks, die Dinger meinst, die mit pthread_mutex_lock verwaltet werden, dann ist es auch bei denen so, dass sie nach einem kill zurückgesetzt werden.
Da sagt "Unix Network Programming" aber was anderes. Mutexes und andere IPC-Objekte könnten ja theoretisch über mehrere Prozesse hinweg verwendet werden. Das System könnte das zwar theoretisch rausfinden - aber zumindest nach den Aussagen in UNP passiert das nicht. (ich meine, dass mich auch einige man-pages davor warnten) Genau dafür kann man ja z.B. cancellation Handler einrichten. Wenn man es aber schlichtweg vergisst, bleiben die bestehen.
-
Harry Hirsch schrieb:
Ponto schrieb:
Wenn du mit Mutex-Locks, die Dinger meinst, die mit pthread_mutex_lock verwaltet werden, dann ist es auch bei denen so, dass sie nach einem kill zurückgesetzt werden.
Da sagt "Unix Network Programming" aber was anderes. Mutexes und andere IPC-Objekte könnten ja theoretisch über mehrere Prozesse hinweg verwendet werden. Das System könnte das zwar theoretisch rausfinden - aber zumindest nach den Aussagen in UNP passiert das nicht. (ich meine, dass mich auch einige man-pages davor warnten) Genau dafür kann man ja z.B. cancellation Handler einrichten. Wenn man es aber schlichtweg vergisst, bleiben die bestehen.
Kannst du mir mal die Stelle aus UNP zitieren?
-
Bittesehr:
UNP Volume 2 (IPC), Seite 174:
When a mutex is shared between processes, there is always a chance that the process can terminate (perhaps involuntarily) while holding the mutex lock. There is no way to have the system automatically release held locks upon process termination. We will see that read-write locks and Posix semaphores share this property.
