Должен ли я беспокоиться об обнаружении ошибок OOM (нехватка памяти) в моем коде C?

Question

Я посвятил большое количество строк кода C меткам очистки / условным обозначениям для неудачного выделения памяти (на что указывает семейство alloc, возвращающее NULL). Меня учили, что это хорошая практика, чтобы при сбое памяти можно было пометить соответствующий статус ошибки и вызывающий мог потенциально выполнить «изящную очистку памяти» и повторить попытку. Теперь у меня есть некоторые сомнения по этому поводу философия, которую я надеюсь прояснить.

Полагаю, возможно , что вызывающий может освободить избыточное пространство буфера или удалить реляционные объекты своих данных, но Я считаю, что вызывающий редко имеет возможность (или находится соответствующий уровень абстракции) для этого. Кроме того, ранний возврат из вызываемой функции без побочных эффектов часто является нетривиальным.

Я также только что обнаружил убийцу Linux OOM, который, кажется, делает эти усилия совершенно бессмысленными на моей основной платформе разработки.

По умолчанию Linux следует оптимистичная стратегия выделения памяти. Это означает, что когда malloc () возвращает не NULL, нет никакой гарантии, что память действительно доступна. Это действительно плохая ошибка. В случае, если это Оказывается, что система вышла из памяти, один или несколько процессов будут быть убитым печально известной ООМ убийца.

Я полагаю, что, вероятно, существуют другие платформы, которые следуют тому же принципу. Есть ли что-то прагматичное, что делает проверку на наличие условий ООМ стоящей?

Answer 1

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

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