SIGSTOP доходит до дочерних процессов с задержкой

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

Близкородственная тема и D state уже обсуждалась, например тут

Секта свидетелей быстрой загрузки (комментарий)

https://stackoverflow.com/questions/6548463/time-to-stop-a-linux-process-using-sigstop

Это BSD, не так ли?

киллы могут задерживаться сколь угодно долго

Но не сорок же секунд! Я бы ещё принял такое на heavy load, но у меня lavg <0.5! Просто нечему задерживать сигнал. Я даже поигрался с nice в обе стороны — ничего не изменилось.

За ссылки благодарю.

Это BSD, не так ли?

Нет, это FreeBSD (про разницу я задолбался объяснять, так что гугл в зубы).

И это ничего не меняет — воспроизводится везде (по крайней мере в POSIX-совместимых UNIX-like), просто с разными задержками.

Но не сорок же секунд

Я бы экспериментировал с самими неостанавливаемыми процессами - наверняка можно найти зависимость от загрузки, от режима, от периферии, через которую идет io и минимизировать время до разумных величин

А почему до mpv должен доходить сигнал отправленный процессу терминала?

с самими неостанавливаемыми процессами

Так они останавливаются (SIGSTOP, как и SIGKILL, не может быть перехвачен (то есть остановка родителя обязана останавливать дочек) или проигнорирован), только не сразу. И было бы пофиг, если бы эта задержка была адекватной (соответствующей нагрузке), но имеем что имеем.

наверняка можно найти зависимость от загрузки, от режима, от периферии, через которую идет io

А ведь в моём тесте mpv читает с диска, и вполне возможно что кэширует не весь трек и тормозить по I/O.

и минимизировать время до разумных величин

Задача не минимизировать задержку а понять её причину. В принципе ты ответил на вопрос ещё в предыдущем комментарии.

А почему до mpv должен доходить сигнал отправленный процессу терминала?

Потому что mpv является дочерним процессом терминала. Остальное в первом абзаце этого комментария.

В моем мире, если сигнал отправляется конкретному процессу, то он и доставляется конкретному процессу и не доставляется его потомкам. Есть фича с отправкой группе процессов(process group), но в посте сказано про отправку сигнала терминалу… что то тут не клеится

Может это от mpv как-то зависит? Например sox’овский play на kill -s 19 или 18 отрабатывает мгновенно.

Кстати, у вас не может быть проблемы извне от других процессов? Типа как

"The other issue is that some processes will detect and react to one of their children being hit with a SIGSTOP. They may SIGCONT the child or they may kill the process outright; in either case it’s probably not what you wanted to happen. Generally you’re safest when the parent of the process you want to pause is something simple, like a shell script. In particular, init (PID 1) is historically somewhat touchy about SIGSTOP’d processes and may often either SIGCONT them or kill them rather than leave them be. This is especially likely if init inherits a SIGSTOP’d process because its original parent process died.

https://utcc.utoronto.ca/~cks/space/blog/unix/SIGSTOPUsesAndCautions

Может «для наглядности» использовать что-нибудь попроще mpv?

SIGSTOP вообще до дочерних процессов не доходит, и не должен доходить, и нигде такого режима работы сигналов никогда не было. Можешь сам даже проверить - посмотри в ps состояние процесса - у стопнутых там буква «T», у твоего плеера её не будет.

Просто из-за зависшего терминала спустя те самые 40 сек заполняется буфер stdout-пайпа от плеера к терминалу, и тот ждёт пока его кто-то разберёт.

но в посте сказано про отправку сигнала терминалу… что то тут не клеится

Само собой имелся в виду графический эмулятор терминала, не tty/pty.

В моем мире, если сигнал отправляется конкретному процессу, то он и доставляется конкретному процессу и не доставляется его потомкам.

Компетентные люди уже объяснили логику, по которой это работает. ☺

Есть фича с отправкой группе процессов(process group)

В случае, описанном в ОП, mpv будет иметь ppid tcsh, а tcsh — ppid эмулятора терминала, и, соответственно, mpv не будет входить в ту же pgrp, в которую входит tcsh, а значит сигнал, посланный в pgrp терминала всё равно до mpv дойдёт с задержкой.

Если сигнал послан напрямую mpv, он реагирует на него мгновенно. SIGSTOP не может быть проигнорирован.

Как выяснилось, сигнал не бродкастится дочерним процессам, и вообще дочерние процессы никак не оповещяются ни ядром, ни родительским процессом, а продолжают работать пока сами не "обнаружат" что родитель получил SIGSTOP, и только тогда у них в state становится T (stopped).

vaddd, firkax, ↑

Кстати, о том что сигналы не бродкастятся, нигде не написано, что и породило этот тред.

О том, что сигнал рассылается процессам-потомкам тоже нигде не написано, и я не вижу ни одной причины такое предполагать.