Не вкурсе, я лично патчил один опен-соурс софт для подобных целей, что позволило рендить то, что валилось постоянно. Там все работает на пределе памяти несколько часов, постоянные ошибки выделения памяти на почти каждый кадр.

Типичный размер видео - более 70 тысяч фреймов, 4-8 тредов, 100% загрузка процессора. Софт 32-битный, LargeAddressAware, так что недостаток памяти очень быстро возникает. Неоптимизированная версия валится примерно через 20-100 кадров и все на этом.

Оом киллер не так часто приходит

Но при этом часто приходит просто зависание системы, по крайней мере на лине

Оверкоммит вообще всю эту фигню с обработкой аллокаций портит

а это кроссплатформенная штука или чисто виндовое? а то в по умолчанию настроенных линуксах вышеупомянутый оверкоммит как раз скорее должен был быть

Виндовое.

Если интересны детали - приложение загружало тучу плагинов. Часть плагинов использовали менеджер памяти приложения, часть пользовалось обычным си рантаймом. Память выделялась по мере надобности, увеличивая кеш программы. В случае нехватки выделенной памяти, кеш программы пополнялся все новыми и новыми выделенными фрагментами памяти. Если системной памяти нет, то различными алгоримами перезапускался рендер до тех пор, пока можно было выделить вообще что-то. Кеш чистился. Индикатор загрузки системной памяти (в винде можно мониторить это) всегда показывал значения вблизи максимально-возможной для x86 процесса. Все это заодно работало и в купе с COM, где тоже могла выделяться своя память. Фрагментации памяти скорей всего не было, потому что размеры почти всегда выделялись примерно равными кусками и все работало с кучей разных тредов. Поскольку не все плагины были адаптированы, максимальный размер подбирался, чтобы случайно в этих плагинах память не была исчерпана за счет мелких аллокаций - иначе просто этот плагин падал - там не было обработок нехватки памяти. Т.е. все работало на верхней границе памяти и начиналось все с запуска си аллокатора, который всегда сообщал, что памяти нет. При рендере очередного фрейма часть плагинов перезапускалось, где свой аллокатор и выделял и освобождал память. Туча тредов, но все работало стабильно.

тлдр, как я понимаю, в том, что простым Box::try_new в таких задачах с такими особенностями никак не обойдешься

Конкретно у виндового маллоца есть проверка на верхний предел аллокации

Но оверкомит там тоже вполне себе норм

Я везде где можно заменил new на new(std::nothrow), оптимизировал работу кеша, ввел рестарт рендера в случае абсолютной невозможности работы, что давало возможность рендерить там, где уже казалось, что невозможно при такой нехватке работать. Итог - скорость рендера была примерно в 2-4 раза, чем на неоптимизированной версии. Это экономило в моем случае недели рендера

А в случае возврата нуля по стд нотроу что делал?

Зависело от места аллокации. В большинстве случаев можно было попробовать заново. В мультитредной среде всегда были случайные окна, когда память появлялась.

Т.е. самая тупая стратегия - это Sleep() на некоторое время и повтор. Но из-за того что был кеш программы, там в большинстве мест этого не требовалось, надо было просто вернуть ошибку. На уровне выше был аналог Sleep()

Sleep тоже требует памяти скорее всего)

Я не спец по ядру винды

Но как минимум в кернеле надо соорудить динамический таймер

В винде нет аналога оверкоммита. Максимальный размер задается по размеру файла подкачки. Будет дико тормозить, но работать.

Тем более куча тредов спит