убирать при выходе или нет

Я понимаю, что уборка - это хорошо. Я также разбираюсь во внутреннем устройстве ОС, поэтому, если я знаю, что мой процесс завершается, его память будет освобождена. Но мне нравится предлагать иную точку зрения. Я в курсе, что это довольно ПЛОХАЯ идея освобождать память при выходе.

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

В целом, операционные системы сильно изменились (основы остались прежними), я понимаю, что этот вопрос можно придумать для A_VERY_PLATFORM_DEPENDENT, но с точки зрения сегодняшнего разработчика приложений он либо застрял (?) В каком-то фреймворке, либо смельчак-программист, который работает над необработанными технологиями, поскольку на него в значительной степени полагаются, я бы назвал VERY_CONTROLLED_ENVIRONMENT.

Для TL;DR: В современных ОС, я думаю, НЕ следует выполнять очистку при выходе. Если ты думаешь, что я ошибаюсь, почему?

PS: Я НЕ говорю о RTOS, я имел в виду контролируемую среду, означающую Windows, Linux, и я никогда не имел в виду разработку драйверов устройств или, в этом отношении, разработку ОС.


person oh_dear_i_love_coding    schedule 07.12.2014    source источник
comment
Я сомневаюсь, что есть разница (в том, что касается необходимости переноса страниц из SWAP в RAM) между приложением free и SO free   -  person bolov    schedule 07.12.2014
comment
Об этом говорили пару недель назад. Я найду и помечу этот дубликат.   -  person Mats Petersson    schedule 07.12.2014
comment
А как насчет ресурсов, не связанных с памятью, например дескрипторов файлов, дескрипторов ядра и т. Д.? И если вы не очищаете ресурсы на основе памяти, как вы можете быть уверены, что они не содержат внешних дескрипторов?   -  person Richard Critten    schedule 07.12.2014
comment
Я бы сказал, что cleanup следует больше рассматривать с точки зрения ресурсов, например сеансы сервера db, эксклюзивные локальные блокировки файлов и т. д., а не только освобожденная память (конечно, любая разумная ОС должна восстанавливать память из завершенных процессов).   -  person πάντα ῥεῖ    schedule 07.12.2014
comment
Дескрипторы @RichardCritten закрываются автоматически при уничтожении таблицы дескрипторов процесса. Как и в случае с ручками ядра, может ли программист приложения их выпустить? Вернее просьба их освободить? это не имеет смысла   -  person oh_dear_i_love_coding    schedule 07.12.2014
comment
Дубликат: stackoverflow.com/questions/677812/ stackoverflow.com/questions/26088499/ blogs.msdn.com/b/oldnewthing/archive/2012/01/05/10253268.aspx Конечно, вам НЕОБХОДИМО каким-то образом очистить файлы блокировки и другие ресурсы - я могу назвать больше чем одно приложение, которое требует ручного вмешательства для перезапуска после сбоя ...   -  person Mats Petersson    schedule 07.12.2014
comment
@all: Я не понимаю, на каких условиях вы, ребята, общаетесь. Либо мне нужно лучше общаться, либо я не знаю НИКАКОГО программирования. Делать то, что в любом случае должно произойти, кажется чертовски неправильным. Конечно, исходя из вашего опыта, вы могли столкнуться с задачей по очистке. Но разве это не твоя РАБОТА? Я имею в виду именно DEAD_CODE. Если есть что-то, что, как вы знаете, следует чистить, вы всегда чистите это. Но придерживаться какого-то стандарта, не понимая его полностью - например, освобождать YOUR_KNOWN_MEMORY - это плохо. Не так ли?   -  person oh_dear_i_love_coding    schedule 07.12.2014
comment
Я делаю вывод: 1. Имейте здравый смысл (предположил, что это очевидно, если вы пишете код) 2. Не очищайте то, что, как вы знаете, в любом случае будет очищено. Если сомневаетесь в гугле, если потом тоже не нашел, что делать, то почистите. Прокомментируйте, если вы не согласны   -  person oh_dear_i_love_coding    schedule 07.12.2014
comment
Пытаться дублировать функциональность ОС в пользовательском коде в тех случаях, когда нет веской причины, просто глупо. Чтобы завершить работу приложения без ошибок, все потоки должны быть остановлены до того, как будут освобождены такие ресурсы, как память. ОС легко может это сделать. Код пользователя не всегда может сделать это (например, он не может безопасно и напрямую остановить поток, работающий на другом ядре, чем поток, запрашивающий завершение), и даже когда это возможно, это дополнительный код, тестирование и отладка для дублирования уже существующих функций и был протестирован. Если не будет плохих последствий, просто прекратите. Наполните valgrind.   -  person Martin James    schedule 08.12.2014


Ответы (1)


Блоки памяти, которые были выгружены, будут добавлены только тогда, когда вы получите к ним доступ. Освобождение блока - это «бухгалтерское» событие, не требующее доступа к памяти. Вы ничего не выиграете, пропустив вызов для освобождения памяти.

Причины всегда освобождать ресурсы вручную при выходе гораздо сильнее: это позволяет использовать инструменты для профилирования памяти, потому что вы можете отличить непреднамеренные утечки от преднамеренных. Уже одной этой причины достаточно, чтобы рекомендовать не пропускать очистку памяти.

person Sergey Kalinichenko    schedule 07.12.2014
comment
«Одной этой причины достаточно, чтобы рекомендовать не пропускать очистку памяти». Ну нет. Это одно преимущество. Это не главный вопрос. - person Martin James; 08.12.2014
comment
@MartinJames: Все, я говорю, что эта причина сама по себе достаточно хороша. Могут быть и другие веские причины (например, возможность спокойно спать по ночам, пока ваш код выполняет критические операции в производственной среде), каждая из которых достаточно сильна в своих правах. Лично я считаю слишком рискованным выпускать код C ++ в рабочую среду без запуска профилировщика памяти и исправления всех предупреждений, которые он сообщает. - person Sergey Kalinichenko; 08.12.2014