⚡️ Linux может передать в SIGCHLD гораздо больше, чем просто «дочерний процесс завершился»

Обычно с дочерними процессами делают так: ловят SIGCHLD, а потом отдельно вызывают waitpid(), чтобы узнать, кто завершился и с каким статусом.

Но есть более интересный режим - SA_SIGINFO.

Если повесить обработчик через sigaction() и включить флаг SA_SIGINFO, ядро передаст в обработчик структуру siginfo_t с деталями по дочернему процессу.

Там уже есть:

• PID дочернего процесса

• статус завершения

• сигнал, если процесс был убит сигналом

• причина генерации SIGCHLD

• код события: завершился, был остановлен, продолжен и так далее

То есть вместо «что-то случилось с ребёнком» программа получает нормальный контекст события прямо в обработчике сигнала.

Примерно так можно понять разницу:

CLD_EXITED - процесс завершился сам

CLD_KILLED - процесс убит сигналом

info->si_pid - какой именно процесс

info->si_status - код выхода или номер сигнала

Это удобная штука для рантаймов, супервизоров, init-систем, job runners и всего, что управляет дочерними процессами.

Вреальном коде не стоит делать тяжёлую работу внутри signal handler. Часто обработчик только фиксирует событие или пишет в pipe/eventfd, а основная логика уже выполняется в обычном цикле программы.

Но сама идея мощная: Linux не просто говорит «ребёнок умер».

Он может сразу сказать, какой именно, как именно и почему.