Может ли системный вызов с не документированным `reintr return 'return` eintr`

I read that there are some systems calls on some systems that can return EINTR although it is not documented (for example stat(2) on Linux). Is this correct?

Если вы не заблокировали все сигналы, каждый системный вызов, который может заблокировать ввод-вывод, может вернуть EINTR. Это общее поведение ядра, поэтому вполне оправдано, что оно не документируется повторно для каждого такого системного вызова. Вы также не ожидаете найти повторяющуюся документацию дляEIOв каждом системном вызове ввода-вывода по той же причине.

В более широком смысле справочные страницы Linux не содержат исчерпывающего списка ошибок, которые они могут возвращать. Мало того, что у вас есть ситуации, подобные описанной выше, в ядре также много уровней, поэтому то, что каждый системный может вернуть , зависит от того, какие драйверы и тому подобное задействованы. Набор возможных значений errno, когда read(2)возвращает -1, будет отличаться, если fdссылается на файл в файловой системе XFS, и если он ссылается на FIFO. Неразумно ожидать, что справочная страница даст объединение всех возможных кодов возврата ошибок; это было бы в значительной степени резюмировать errno(3), если бы это произошло.

What can be wrong using this approach? It is really recommended/needed?

Слепой перезапуск системных вызовов может быть неправильным в вашем приложении. Системные вызовы возвращают EINTR, чтобы дать вашему приложению возможность обрабатывать сигнал в контексте вызова, а не в контексте обработчика сигнала. Например, это может помочь вам избежать глобальных переменных.

Один взгляд на это см. вEINTRи «Для чего это полезно» .

Обратите также внимание на пункт sigaction, поднятый в этой статье :, вы можете управлять этим поведением с помощьюSA_RESTART. Если ваш следующий вопрос заключается в том, следует ли установить флаг на 1 или на 0, то ответ таков: это зависит от вашего приложения.