Вопрос по – ОПЕРАЦИОННЫЕ СИСТЕМЫ; ресурсы автоматически очищаются

7

Из этого ответа:Когда обработчик завершения C ++ является правильным (TM)?

Было бы неплохо иметь список ресурсов, которые «являются». и «не являются»; автоматически очищается операционной системой при выходе из приложения. В вашем ответе было бы неплохо, если бы вы могли указать ОС / ресурс и, предпочтительно, ссылку на какой-либо документ (при необходимости).

Очевидный:

Память: Да, автоматически очищается. Вопрос. Есть ли исключения?

@Neil: Ваша точка зрения? Неправильно очищенное соединение с БД может привести к потере данных. Как таковой, это ресурс, который должен быть хорошо очищен. Martin York
Комплексные ресурсы. Такие, как услуги (например, БД). Martin York
Соединение с БД! = Служба БД. Сначала вы использовали слово «сервис», а не я. anon
Услуги обычно не относятся к процессам. anon
как насчет контр-примера, чтобы дать нам представление о том, что вы хотите? skaffman

Ваш Ответ

4   ответа
3

с чем вы можете справиться, должно управляться операционной системой, поэтому вы получаете только дескриптор. Это включает, но не ограничивается следующее (список скопирован из документации MSDN для API CloseHandle ()):

Communications device 
Console input 
Console screen buffer 
Event 
File 
File mapping 
Job 
Mailslot 
Mutex 
Named pipe 
Process 
Semaphore 
Socket 
Thread 
Token 

Все они должны быть восстановлены ОС, когда приложение закрывается, хотя, возможно, не сразу, в зависимости от их использования другими процессами.

Другие операционные системы работают таким же образом. Трудно представить себе ОС, достойную ее названия (я исключаю встроенные системы и т. Д.), Где это не так - управление ресурсами является главной целью операционной системы.

У меня есть приложение, которое в случае сбоя обычно оставляет за окном консоль зомби (это приложение для Windows, которое также создает окно консоли). Я должен периодически перезагружаться, чтобы вычистить их все.
Мы можем согласиться с тем, что все, что управляется через дескриптор, будет в конечном итоге выпущено ОС. Martin York
Это зависит от того, что вы подразумеваете под освобождением. Сбой процесса не может удерживать Mutex (другой процесс, ожидающий Mutex, получит право собственности с WAIT_ABANDONED). Но для Семафора все по-другому. Если другой процесс ожидает этого, он зависает. Если вы убьете зависшее приложение, система восстановит объект Семафор.
3

ить работу и содержат утечки. ОС должна быть надежной и не истощать ресурсы даже в условиях плохо написанных приложений. Это также относится к ресурсам вне ОС. Службы, которые передают ресурсы процессам, должны освобождать эти ресурсы при выходе из процесса. Если они этого не делают, это ошибка, которую необходимо исправить.

Если вы ищете программные артефакты, которые могут сохраняться после завершения процесса, в Windows у вас есть по крайней мере:

Registry keys that are created without REG_OPTION_VOLATILE Files created without FILE_FLAG_DELETE_ON_CLOSE Event log entries Paper that was used for print jobs
Ну, я определенно не определяю COM-сервер как ОС. COM - это просто серверная архитектура, такая же, как у Apache. Но это не так, я чувствую.
Да, это идеал. Но не все ресурсы принадлежат ОС. Martin York
Какие ресурсы в конечном итоге не принадлежат ОС?
@Neil - это зависит от того, что вы определяете как ОС. Работает ли COM-сервер в отдельном процессе, который был создан вами через CoCreateInstance, как управляемый ресурс ОС? (в этом случае подсистема COM отключит сервер при выходе)
@Martin - ваш заголовок говорит о ресурсах ОС :) Даже в этом случае это ошибка в компоненте или сервисе, который выделил ресурс.
5

которые Windows не очищает при сбое или выходе из приложения без явного их освобождения, в основном потому, что ОС не знает, важно ли их оставить или нет.

Temporary files -- as others have mentioned. Globally registered WNDCLASSes ("No window classes registered by a DLL are unregistered when the DLL is unloaded. A DLL must explicitly unregister its classes when it is unloaded." MSDN) If your global window class also has a class DC, then that DC will leak as well. Global ATOMs (a relatively limited resource). Window message IDs created with RegisterWindowMessage. These are designed to leak, since there's no UnregisterWindowMessage. Semaphores and Events aren't technically leaked, but when the owning application goes away without signalling them, then other processes can hang. This is not true for a Mutex. If the owning application goes away, other processes waiting on that Mutex are released. There may be some residual weirdness on Windows XP and earlier if you don't unregister a hot key before exiting. Other applications may be unable to register the same hot key. On Windows XP and earlier, it's not uncommon to have a zombie console window live on after a process crashes. (Specifically, a GUI application that also creates a console window.) It shows up on the task bar. All you can do is minimize, restore, or move the window. Buggy drivers can be aggravated by apps that don't explicitly release resources when they exit. Non-paged pool leaks are fairly common. Data copied to the clipboard. I guess that doesn't really count because it's owned by the OS at that point, not the application that put it there. Globally installed hooks aren't unloaded when the installing process crashes before removing the hook.
3

not быть очищенным - дескриптор освобожден, но файл не удален

@Neil: Вы указываете? Это ресурс, который не очищается автоматически операционной системой. Учитывая возможность, приложение должно было быть очищено приложением, но утечка произошла из-за проблемы. То, что я считаю, это весь смысл этой дискуссии. Martin York
Какой вариант использования для временных файлов, которые не должны пережить процесс? Единственное (неправильное) использование, которое я вижу, является своего рода вторичной памятью, но вы должны полагаться на свою ОС & apos; управление виртуальной памятью, чтобы сделать это для вас.
Но это, очевидно, не тот случай, когда процесс должен удалять свои временные файлы (или то, что должна делать ОС). Подумайте о своих файлах резервных копий текстового процессора - вы не хотите их терять, когда Word (или что-то еще) паникует.
Можно утверждать, что в конечном итоге все будет очищено. Проблема в том, что неаккуратное освобождение ресурса может привести к другим проблемам. В этом случае мы можем исчерпать свободное пространство в файловой системе, пока файлы не будут повторены более чистыми процессами. Martin York
Хороший вопрос. Но временные файлы похожи на невыполненные задания на печать - у ОС просто нет информации, чтобы решить, следует ли их немедленно удалять из процесса. Но все они будут пожинены / очищены / очищены / удалены в какой-то момент.

Похожие вопросы