Вопрос про состояния процессов

https://major.io/2009/06/15/two-great-signals-sigstop-and-sigcont/

Довольно очевидно, что ядро тупо не начинает исполнять процесс до прихода сигнала.

а как это реализовано в самом процессе? ведь процесс ожидает определённый сигнал

так если сигстоп послать это остановлен будет, а не сон, разве нет?

Он ничего не ожидает, и вообще может не исполняться. Когда приходит сигнал, просто вызывается функция-обработчик, заданная через signal() или sigaction().

вызывается функция-обработчик, заданная через signal() или sigaction().

она вызывается из самого процесса?

Как ты себе такое представляешь?

вот я тебя и спрашиваю. тоесть это ядро вызывает функцию?

Думаю, что процесс переодически просыпается*, проверяет, не нужно ли что-либо сделать, и снова засыпает (говорит планировщику запустить след. процесс).
Как-то так:

while True:
    sleep(100)
    if check_smth():
        # do something
    else:
        # yeald to scheduler

да, ядро, но в контексте процесса. теперь ты знаешь что нужно гуглить ;)

Как на языке shell-scripting реализовать сон до получения определённого сигнала (на сколько я понимаю, с помощью kill -SIGUSR1)?

  trap 'kill ${P}' USR1

  while sleep 86400 & P=${!} ; wait ${P} ; do : ; done

Не вполне корректно (если сигнал придёт во время перезапуска sleep, он пропадёт), но если тебя это волнует, доработать, а также добавить определение того, каким именно сигналом прерван wait, несложно.

Сон (не путать с вытеснением планировщиком) начинается с вызова api, который, в конечном итоге, передает управление ядру, а то, в свою очередь, переставяет процесс из очереди исполняемых процессов в очередь ждущих (или в несколько очередей сразу).

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

Если ты хочешь, чтобы процесс спал, установи обработчик сигналов, которых ты ждешь, размаскируй эти сигналы, а затем выполни блокирующийся, но прерываемый системный вызов. Например, usleep(). Когда ядро получит сигнал для твоего процесса, и доставит сигнал до него, оно прервёт выполнение системного вызова. Процесс увидит это как выход из системного вызова с errno=EINTR.

А вообще для ожидания конкретно сигналов есть блокирующийся системный вызов sigwait().

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

RTFM: man 7 signal

Если ты хочешь усыпить процесс именно до получения сигнала, то тебе поможет, например, man 3 sigwait. В баше используй built-in trap; аналогов sigwait там нету, поэтому можешь делать в цикле sleep 9999999.

Для сна до прихода сигнала из программы вызывают pause() или более продвинутая версия sigsuspend(), позволяющая избежать race condition.

Из кода просто вызывают эту функцию и она звершится по приходу сигнала. В каком именно внешнем состоянии (D, R, S, T, Z) будет процесс вам проще посмотреть самому, написав и скомпилив 10 строк.

Сигналы приходят через ядро, но не через планировщик. Ядро смотрит сигнальную маску процесса и, если сигнал принимается к обрабоке, изменяет стек процесса и адрес выполняемой иструкции, так что процесс начинает выполнять свой код обработчика сигнала. И, если процесс спал в ожидании сигнала его переводят в очередь активных задач, ожидающих когда планировщик запустит их.

На shell не вызвать sigsuspend(), пишут всякие костыли. Причём, ЕМНИП, trap это башизм. И работа с сигналами в bash'е получается кривая и не удобная...

Ржали всем офисом.

SIGSTOP/SIGCONT

И пусть тебя не смущают всякие глупости. Эти сигналы они не процессу, а операционке.