> Вот именно: вредная идея в принципе этот самый killerА это не идея. Это просто пережиток UNIX-ахитектуры, её самая мрачная часть: системный вызов fork
Даже не буду вдаваться в детали, для чего это было изначально, но сейчас это одна из замен IPC в сочетании с UNIX pipes. Материнский процесс порождает дочерние ради вопросов многозадачности и обмена данными. Проблема в том, что вся память материнского процесса копируется в дочерние. И там по идее применяется COW для оперативки, чтобы не занимать слишком много места. Предварительно объявляется pipe для обмена данными.
То есть если материнский процесс запустился и запросил 16Гб оперативной памяти, то _потенциально_ по столько же захватят детки. В этой ситуации, когда весь юзерспейс так работает нет никакой возможности предсказать сколько реально приложению нужно оперативной памяти. Вот ядро и не пытается. Ядро всегда утвердительно отвечает на запросы выдачи RAM, а когда вся память кончится то OOM Killer без спросу прибьёт тот процесс, который плохо лежит.
Вы не единственный человек, который посчитал, что это плохая практика. Например, разработчики операционной системы VMS посчитали, что fork не безопасен (бездумное копирование данных, потенциально с ошибками) и порождает проблемы. Поэтому было принято решение:
1. Не делать системный вызов fork
2. Отказать приложению, если оперативной памяти вместе с виртуальной не достаточно. Приложение получит исключение (обработает или покрашится), а вновь запускаемые приложения вообще не возможно запустить в состоянии OOM.
3. Для решения задач IPC предложить IPC
4. Для решения задач многопоточности предложить API для потоков/тредов, а не плодить клоны процессов
5. Для запуска дочерних процессов предложить отдельное API, которое их запускает, а не копирует с родителя.
Ну то есть pthreads-то есть, но он появился сильно позже (90-е) чем fork (70-е), и вы можете писать приложение не форкаясь, но вот только если вы посмотрите на UNIX-юзерспейс, вы осознаете, что Init, включая его молодежные и популярные версии на самом деле считают все процессы в ОС форком первого процесса, процесса init. Значит чтобы это победить нужно еще и предоставить некоторую объектную модель работы с процессами, которая живет отдельно, а не иерархично копируется.
В итоге у противников архитектуры, которая предполагает наличие fork получилось так, что создание процесса стало трудоёмкой по времени задачей, а наличие богатого IPC стало обязательным в юзерспейсе. Зато потоки наоборот стали простыми и дешевыми. Но да, операционная система построенная на этих принципах не имеет OOM и не нуждается в нем.
Сама по себе оригинальная VMS мертва, но её архитектуру наследуют VMS-подобные, если можно так сказать, ОС, одной из которых является Windows NT (не та которые 9к). При разработке WSL1 Windows обзавелся очередной реализацией fork в рамках обновленных компонентов POSIX-совместимости. Они даже писали публикации с просьбами избавиться от него в UNIX-like, потому что он привносит больше проблем, чем что-то там решает. Вроде этой: https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
А потом плюнули и пихнули WSL2 в виртуалку. Пусть сами играют в свои fork-exec, OOM Killer и прочие пережитки прошлого, под управлением гипервизора с лимитом на ресурсы RAM.
