⚡️ 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 не просто говорит «ребёнок умер».
Он может сразу сказать, какой именно, как именно и почему.
