de cette réponse: Quand est-il terminé en C ++ gestionnaire la bonne chose (TM)?
Il serait bon de disposer d'une liste de ressources qui "sont" et "ne sont pas" nettoyées automatiquement par le système d'exploitation lorsqu'une application arrête. Dans votre réponse, ce serait bien si vous pouvez spécifier le système d'exploitation / ressource et de préférence un lien vers un document de documentation (le cas échéant).
l'évident:
Mémoire: Oui, nettoyé automatiquement. Question. Y a-t-il des exceptions?
4 Réponses :
Toute exception est une bogue - les applications peuvent et font des crash et contiennent des fuites. Un système d'exploitation doit être fiable et ne pas échapper aux ressources même face aux applications mal écrites. Cela s'applique également aux ressources non du système d'exploitation. Les services qui distribuent des ressources aux processus doivent libérer ces ressources lorsque le processus se déroule. S'ils ne le font pas, c'est un bug qui doit être corrigé.
Si vous recherchez des artefacts de programme qui peuvent persister au-delà de la sortie de processus, sur Windows, vous avez au moins:
Oui c'est l'idéal. Mais toutes les ressources ne sont pas possédées par le système d'exploitation.
@Martin - Votre titre indique les ressources du système d'exploitation :) Même alors, c'est un bogue dans le composant ou le service qui a affecté la ressource.
Quelles ressources ne possèdent pas finalement par le système d'exploitation?
@Neil - Cela dépend de ce que vous définissez en tant que système d'exploitation. Un serveur COM est-il exécuté dans un processus distinct créé par vous via CoCreateInstance une ressource gérée par système d'exploitation? (Dans ce cas, le sous-système COM désactivera le serveur si vous quittez)
Eh bien, je ne définis certainement pas un serveur COM que le système d'exploitation. Com est juste une architecture de serveur, de la même manière que Apache est. Mais c'est hors du point, je me sens.
Les poignées de fichier appartiennent au système d'exploitation, mais les fichiers sont des ressources détenues par le système de fichiers. Un processus peut appartenir à l'OS mais le service fonctionnant à l'intérieur des processus (AKA A DB) n'est pas la propriété du système d'exploitation.
@Michael: édité le titre. Espérons que ce ';' efface ma signification.
@Martin je déteste le dire, mais je pense que vous devez suivre les architectures du système d'exploitation. Un système de fichiers est un moyen de structurer une ressource OS - la ressource est toujours la propriété du système d'exploitation. F
Je déteste dire mais je ne suis pas d'accord :-) Un FS est quelque chose que le système d'exploitation peut avoir ou non besoin et comme une telle ressource potentielle. Mais il a hérité de son propre état et de ses ressources qu'il gère indépendamment du système d'exploitation. Cela devient très aparent lorsque vous séparez phisiquement un FS du système d'exploitation (pensez à un système d'exploitation qui n'a qu'un FS via un stockage de réseau).
@Martin dans le cas d'une ressource en réseau comme NFS Le système de fichiers appartient toujours au système d'exploitation sur le serveur NFS.
@Neil Butterworth: Pas de désaccord là-bas. Mon point est toujours debout.
Dans Windows, à peu près tout ce que vous pouvez obtenir la poignée devrait être géré par le système d'exploitation - c'est pourquoi vous obtenez seulement une poignée. Cela inclut, mais n'est pas limité Tom Ce qui suit (liste copiée de MSDN Docs for Callhandle () API):
Communications device Console input Console screen buffer Event File File mapping Job Mailslot Mutex Named pipe Process Semaphore Socket Thread Token
Nous pouvons convenir que tout ce qui est contrôlé via une manche sera éventuellement publié par le système d'exploitation.
Cela dépend de ce que vous entendez par publié. Un processus écrasé ne peut pas détenir un mutex (un autre processus attendant sur le mutex sera propriétaire avec un wait_abandoned). Mais c'est différent pour un sémaphore. Si un autre processus attend sur cela, il est suspendu. Si vous tuez l'application suspendue, le système récupère l'objet Sempaphore.
J'ai une application qui, lorsqu'il se bloque, des laisse régulièrement derrière une fenêtre de console de zombie (c'est une application Windows, la fenêtre de la console crée également une fenêtre de console). Je dois redémarrer périodiquement pour les nettoyer tous.
Les fichiers temporaires sont un bon exemple de quelque chose qui sera pas être nettoyé - la poignée est libérée, mais le fichier n'est pas supprimé
Un bon point. Mais les fichiers temporaires sont comme des emplois d'impression exceptionnels - le système d'exploitation ne dispose tout simplement pas des informations nécessaires pour décider sur la fois, ils doivent immédiatement être supprimés immédiatement une terminaison de processus. Mais ils seront tous récoltés / effacés / rinçus / supprimés à un moment donné.
On pourrait soutenir que tout sera éventuellement nettoyé. Le problème est que la répartition des ressources désordonnées peut conduire à d'autres problèmes. Dans ce cas, nous pouvons être sortis de l'espace libre dans le système de fichiers jusqu'à ce que les fichiers soient répétés par un processus de nettoyage.
Mais ce n'est évidemment pas le cas qu'un processus devrait supprimer ses fichiers temporaires (ou que le système d'exploitation devrait). Considérez vos fichiers de sauvegarde de mot-processeur - vous ne voulez pas les perdre lorsque des paniques (ou autre).
@Neil: vous pointez? C'est une ressource qui n'est pas nettoyée automatiquement par le système d'exploitation. Compte tenu de l'optériorité, il aurait dû être nettoyé par l'application, mais a été divulguée à cause d'un problème. Que je crois que tout le point de cette discussion.
Quel est le cas d'utilisation pour les fichiers temporaires qui ne doivent pas survivre au processus? Le seul (MIS) que je vois est comme une sorte de mémoire secondaire - mais vous devez compter sur la gestion de la mémoire virtuelle de votre système d'exploitation pour le faire pour vous.
Pour afficher les PDF générés à partir de données de programme, ils ont été enregistrés dans des fichiers temporaires dans un programme que j'ai travaillé.
@Joseph: Les fichiers temporaires peuvent être utilisés pour cacher des données qui pourraient ne pas correspondre dans l'espace d'adresses virtuel.
Il existe certaines ressources obscures que Windows ne nettoie pas lorsqu'une application se bloque ou sort sans les libérer explicitement, principalement parce que le système d'exploitation ne sait pas s'il est important de partir ou non.
wndclass ES ("Aucune classe de fenêtre enregistrée par une DLL n'est désenregistré lorsque la DLL est déchargée. Une DLL doit interrompre explicitement les classes lorsqu'il est déchargé." MSDN ) Si votre classe de fenêtre globale a également une classe DC, alors que DC va aussi fuir.
- global
Atom S (une ressource relativement limitée).
- ID de message de fenêtre créé avec
registerwindowmessage < / code> . Ceux-ci sont conçus pour fuir, car il n'y a pas de UnregisterWindowMessage .
- SEMAPHORES ET ÉVÉNEMENTS N'EST PAS FULLIQUÉS TECHNIQUEMENT, mais lorsque l'application de propriété disparaît sans les signaler, les autres processus peuvent être suspendus. Ce n'est pas vrai pour un mutex. Si la demande de propriété disparaît, d'autres processus attendent sur ce mutex sont libérés.
- Il peut y avoir une certaine étrangeté résiduelle sur Windows XP et plus tôt si vous ne enregistrez pas un clé à chaud avant de quitter. D'autres applications peuvent ne pas être incapables d'enregistrer la même clé à chaud.
- sur Windows XP et plus tôt, il n'est pas rare d'avoir une fenêtre de console de zombie en direct après un processus de processus. (Plus précisément, une application d'interface graphique crée également une fenêtre de console.) Il apparaît sur la barre des tâches. Tout ce que vous pouvez faire est de minimiser, de restaurer ou de déplacer la fenêtre.
- Les pilotes de buggy peuvent être aggravés par des applications qui ne relâchent pas explicitement des ressources lorsqu'ils quittent. Les fuites de piscine non pagies sont assez courantes.
- Les données copiées dans le presse-papiers. Je suppose que cela ne compte pas vraiment parce que c'est la propriété du système d'exploitation à ce stade, pas la demande qui la mettait là-bas.
- Les crochets installés dans le monde ne sont pas déchargés lorsque le processus d'installation se bloque avant de retirer le crochet.
Que diriez-vous d'un contre-exemple pour nous donner une idée de ce que vous êtes après?
Ressources complexes. Tels que des services (une DB par exemple).
Les services n'appartiennent généralement pas aux processus.
@Neil: votre point d'être? Une connexion DB non nettoyée correctement est un potentiel de perte de données. En tant que tel, c'est une ressource qui devrait être nettoyée bien.
DB Connection! = DB Service. Vous avez utilisé le service de mot d'abord, pas moi.
Je souligne mon commentaire alors. Une ressource complexe. Comme une ressource d'un autre service (une connexion DB).