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?
A menos que você tenha bloqueado todos os sinais, todas as chamadas do sistema que podem ser bloqueadas na E / S podem retornar EINTR . Esse é um comportamento genérico do kernel, por isso, é justificável que ele não seja documentado repetidamente para cada tipo de syscall. Você também não esperaria encontrar documentação repetida para EIO em cada I / O syscall pelo mesmo motivo.
Mais amplamente, as man pages do Linux não listam os erros que podem retornar de forma exaustiva. Além de você ter situações como as descritas acima, também há muitas camadas no kernel, então o que cada syscal pode retornar depende de quais drivers e coisas estão envolvidas. O conjunto de possíveis valores de errno quando read(2) retornará -1 será diferente se o fd referir-se a um arquivo em um sistema de arquivos XFS do que se se referir a um FIFO. Não é razoável esperar que a página man forneça a união de todos os possíveis códigos de retorno de erro; ele recapitularia em grande parte errno(3) se isso acontecesse.
What can be wrong using this approach? It is really recommended/needed?
A reinicialização cega de syscalls pode não ser a coisa certa em seu aplicativo. O recurso syscalls retorna EINTR para dar ao seu aplicativo uma chance de lidar com o sinal no contexto de chamada, em oposição ao contexto do manipulador de sinal. Isso pode ajudá-lo a evitar variáveis globais, por exemplo.
Para obter uma perspectiva sobre isso, consulte EINTR e o que é bom para .
Observe também o sigaction apontado nesse artigo: você pode controlar esse comportamento com SA_RESTART . Se a sua próxima pergunta for se você deve definir o sinalizador como 1 ou 0, a resposta é que isso depende do seu aplicativo.