Search code examples
socketseofnonblockingfile-descriptor

What is blocking behaviour at EOF

Would it be possible that a read on a file descriptor (in this case a non-blocking socket) that has reached EOF would block before EOF can be detected?

Like in the following sequence:

  1. read returns -1 and errno is set to EWOULDBLOCK or EAGAIN
  2. read returns 0, which means that EOF has been reached

or

would it always look like this in case it is waiting for data:

  1. read returns -1 and errno is set to EWOULDBLOCK or EAGAIN
  2. read returns a value > 0
  3. read returns 0, which means that EOF has been reached

That is, does EWOULDBLOCK imply that there will be more data available or is it possible that there are no more data when the file descriptor becomes available again?

Solution

  • ... does EWOULDBLOCK imply that there will be more data available

    No. EWOULDBLOCK only says that there are currently no data available. It does not make any statements about future traffic, i.e. if new data will be arrive or if the connection will be closed.

    If the connection is shutdown by the peer and the FIN received and fully processed by the local OS, then recv will not return EWOULDBLOCK but will signal the EOF (assuming all data so far where read already).