Handling read() errors - Unix

This is a discussion on Handling read() errors - Unix ; Hello! Suppose read() system call returns -1. There are many causes of the error. I exactly know that if errno = EINTR, then I can safety restart system call as follows: while( (rc = read(sock, buf, count)) == -1 and ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Handling read() errors

  1. Handling read() errors

    Hello!

    Suppose read() system call returns -1.
    There are many causes of the error.

    I exactly know that if errno = EINTR, then I can safety restart
    system call as follows:
    while( (rc = read(sock, buf, count)) == -1 and errno == EINTR)
    {
    // Do nothing.
    }

    Are there another cases when I can safety restart read()?
    If so, what errno values correspond to these cases?

    Thanks!


  2. Re: Handling read() errors

    Krivenok Dmitry wrote:
    > Suppose read() system call returns -1.
    > There are many causes of the error.


    > I exactly know that if errno = EINTR, then I can safety restart
    > system call as follows:
    > while( (rc = read(sock, buf, count)) == -1 and errno == EINTR)
    > {
    > // Do nothing.
    > }


    > Are there another cases when I can safety restart read()?
    > If so, what errno values correspond to these cases?


    If you have opened the file in non-blocking mode you may
    get EAGAIN or EWOULDBLOCK if there were no data to be read.
    This is probably the second "normal" case where calling
    read() again makes sense. If there are others depends on
    the what kind of object you're reading from - if you're
    reading from a socket and you get ETIMEDOUT because the
    transmission timed out there might be some reasons to call
    read() again. And if your system is struggling because it
    doesn't have enough memory you may get ENOBUFS or ENOMEM.
    In that case you also might decide to try your luck again,
    perhaps after a short pause to give the system time re-
    claim enough memory.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

  3. Re: Handling read() errors

    On Apr 5, 4:23 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
    > Krivenok Dmitry wrote:
    > > Suppose read() system call returns -1.
    > > There are many causes of the error.
    > > I exactly know that if errno = EINTR, then I can safety restart
    > > system call as follows:
    > > while( (rc = read(sock, buf, count)) == -1 and errno == EINTR)
    > > {
    > > // Do nothing.
    > > }
    > > Are there another cases when I can safety restart read()?
    > > If so, what errno values correspond to these cases?

    >
    > If you have opened the file in non-blocking mode you may
    > get EAGAIN or EWOULDBLOCK if there were no data to be read.
    > This is probably the second "normal" case where calling
    > read() again makes sense. If there are others depends on
    > the what kind of object you're reading from - if you're
    > reading from a socket and you get ETIMEDOUT because the
    > transmission timed out there might be some reasons to call


    May you enumerate these reasons?

    I always thought that ETIMEDOUT may be got only in case of
    exceeding retransmission timeout.
    Am I right?

    > read() again. And if your system is struggling because it
    > doesn't have enough memory you may get ENOBUFS or ENOMEM.
    > In that case you also might decide to try your luck again,
    > perhaps after a short pause to give the system time re-
    > claim enough memory.
    > Regards, Jens
    > --
    > \ Jens Thoms Toerring ___ j...@toerring.de
    > \__________________________ http://toerring.de




  4. Re: Handling read() errors

    Krivenok Dmitry wrote:
    > May you enumerate these reasons?


    > I always thought that ETIMEDOUT may be got only in case of
    > exceeding retransmission timeout.
    > Am I right?


    As far as I can tell, yes. But timing out does, as far as I
    understand it, does not necessarily mean that the connection
    is completely dead, it might only mean that no response from
    the other side has been seen duing a certain time interval.
    There might be situations where it could make sense to wait
    some more and thus call read() again.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

  5. Re: Handling read() errors

    In article <57ksg4F2d282iU1@mid.uni-berlin.de>,
    jt@toerring.de (Jens Thoms Toerring) wrote:

    > Krivenok Dmitry wrote:
    > > May you enumerate these reasons?

    >
    > > I always thought that ETIMEDOUT may be got only in case of
    > > exceeding retransmission timeout.
    > > Am I right?

    >
    > As far as I can tell, yes. But timing out does, as far as I
    > understand it, does not necessarily mean that the connection
    > is completely dead, it might only mean that no response from
    > the other side has been seen duing a certain time interval.
    > There might be situations where it could make sense to wait
    > some more and thus call read() again.


    I suspect not. I think that when ETIMEDOUT is returned it implies that
    the stack has killed the connection as a result of the acknowledgement
    timeout.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  6. Re: Handling read() errors

    Barry Margolin wrote:
    > In article <57ksg4F2d282iU1@mid.uni-berlin.de>,
    > jt@toerring.de (Jens Thoms Toerring) wrote:


    > > Krivenok Dmitry wrote:
    > > > May you enumerate these reasons?

    > >
    > > > I always thought that ETIMEDOUT may be got only in case of
    > > > exceeding retransmission timeout.
    > > > Am I right?

    > >
    > > As far as I can tell, yes. But timing out does, as far as I
    > > understand it, does not necessarily mean that the connection
    > > is completely dead, it might only mean that no response from
    > > the other side has been seen duing a certain time interval.
    > > There might be situations where it could make sense to wait
    > > some more and thus call read() again.


    > I suspect not. I think that when ETIMEDOUT is returned it implies that
    > the stack has killed the connection as a result of the acknowledgement
    > timeout.


    Your guess is probably a lot better then mine, not having much
    experience with the fine details of networking stuff. I just had
    a look at Stevens Network Programming and SUSv3and found nothing
    explicitely saying that the connection would be dead after errno
    bein set to ETIMEDOUT, so I included it into the list of cases
    where it sometimes might be reasonably to restart a read() call,
    assuming that it also could mean that some package might arrive
    even after that failure.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

+ Reply to Thread