Как упомянуто в справочной странице сигнала (7),
Interruption of system calls and library functions by signal handlers
If a signal handler is invoked while a system call or library function call is blocked, then either:
* the call is automatically restarted after the signal handler returns; or
* the call fails with the error EINTR.
Which of these two behaviors occurs depends on the interface and whether or not the signal handler was established using the SA_RESTART flag (see sigaction(2)). The details vary across UNIX systems; below, the details for
Linux.
If a blocked call to one of the following interfaces is interrupted by a signal handler, then the call will be automatically restarted after the signal handler returns if the SA_RESTART flag was used; otherwise the call will
fail with the error EINTR:
* read(2), readv(2), write(2), writev(2), and ioctl(2) calls on "slow" devices. A "slow" device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. If an I/O call on a
slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred). Note that a (local) disk is not a
slow device according to this definition; I/O operations on disk devices are not interrupted by signals.
Поскольку упоминается, что обработчик сигнала прерывает заблокированный вызов одного из следующих интерфейсов (чтение, запись), то вызов будет автоматически перезапущен после того, как обработчик сигнала вернется, если использовался флаг SA_RESTART, это означает, что в случае заблокированного системного вызова чтения / записи процесс должен находиться в состоянии TASK_INTERRUPTIBLE.
Но когда я пытался найти заблокированные системные вызовы, переводящие процесс в состояние TASK_UNINTERRUPTIBLE, я обнаружил https://unix.stackexchange.com/questions/62697/why-is-i-o-uninterruptible и Почему ввод / вывод в Linux бесперебойен? и в обоих в тех местах, где упоминается, что заблокированный вызов ввода / вывода (чтение, запись) поместит процесс в TASK_UNINTERRUPTIBLE.
Также здесь упоминается: https://access.redhat.com/sites/default/files/attachments/processstates_20120831.pdf
The Uninterruptible state is mostly used by device drivers waiting for disk or network I/O. When the process
is sleeping uninterruptibly, signals accumulated during the sleep are noticed when the process returns from
the system call or trap. In Linux systems. the command ps -l uses the letter D in the state field (S) to
indicate that the process is in an Uninterruptible sleep state. In that case, the process state flag is set as
follows:
p->state = TASK_UNINTERRUPTABLE
LEARN MORE: Read more about D states in the Red Hat Knowledgebase:
https://access.redhat.com/knowledge/solutions/59989/
Это немного сбивает с толку.
Также я хочу знать другие заблокированные системные вызовы, которые могут перевести процесс в состояние TASK_UNINTERRUPTIBLE.