Переводит ли заблокированный системный вызов на чтение / запись процесс в состояние TASK_UNINTERRUPTIBLE или TASK_INTERRUPTIBLE? - PullRequest
0 голосов
/ 14 мая 2019

Как упомянуто в справочной странице сигнала (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.

1 Ответ

3 голосов
/ 15 мая 2019

При использовании системных вызовов read(2) или write(2) тип сна зависит от типа файла, к которому осуществляется доступ.В цитируемой вами документации «медленные» устройства - это те, в которых read/write будет работать непрерывно, а «быстрые» устройства - это те, которые будут работать непрерывно (состояние непрерывного сна называется D для «Disk Wait», поскольку изначальноread/write на дисковых файлах была наиболее распространенной причиной этого типа сна).

Обратите внимание, что «блокировка» технически относится только к прерыванию сна.

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

...