CODEWITHSUNDEEP
pipeiosockets
Brian Bi
Brian Bi

Reputation: 119382

If an I/O function cannot fail with EINTR, does that mean it never blocks?

For example, consider fdopen. I have been wondering whether it's possible for this to block, if, say, the file descriptor argument refers to a pipe or socket. A Google search hasn't turned up anything useful. On one hand, it seems to me that it shouldn't block because it just "associates" a stream with a file descriptor. On the other hand, I wonder whether the implementation has license to pre-fill the buffers upon the fdopen call, which could block if the newly opened pipe or socket has no data available for reading yet.

The possible errors are EMFILE, EBADF, EINVAL, and ENOMEM. I assume that any blocking I/O function may potentially be interrupted by a signal, so if it were possible for fdopen to block, then EINTR would also be given as a possible error. Since that isn't the case, can I assume that fdopen never blocks? Does this generalize to other I/O functions too?

Upvotes: 4

Views: 82

Answers (1)

Radu
Radu

Reputation: 1128

fdopen() is a libc call that uses various system calls like fcntl() to check the status of the file. These syscalls can block and/or return additional error codes compared to what fdopen() returns. For example, fcntl() can block and also return EINTR. The implementation of fdopen() transparently deals with the recoverable error conditions.

Bottom line, fdopen() can block as it uses at least a blocking syscall. The same reasoning applies to other I/O-related libc functions.

Upvotes: 1

Related Questions