Wird ein Programm sauber beendet wenn man das Konsolenfenster schließt?
-
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.