Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001429 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Omission 2020-12-02 16:57 2021-04-01 09:34
Reporter Konrad_Schwarz View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Konrad Schwarz
Organization Siemens AG
User Reference recvfrom timeout
Section recvfrom
Page Number 1
Line Number 1
Interp Status ---
Final Accepted Text Note: 0005281
Summary 0001429: recvfrom does not specify the errno on timeout when the SO_RCVTIMEO option has been set
Description POSIX specifies the SO_RCVTIMEO socket option, that causes a receiving call on a socket to timeout when an error occurs. However, the recvfrom() (and presumably the related calls recv(), read() etc.) do not specify what errno is set to in this case.
Desired Action According to the Linux socket(7) man page, EAGAIN/EWOULDBLOCK is returned in this case. (ETIMEDOUT would also kind of make sense and is what I assumed originally).

Add to the description of EGAIN in ERRORS the possibility of a timeout due to SO_RCVTIMEO.
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0005148)
geoffclare (manager)
2020-12-03 10:39

The required behaviour is specified in XSH 2.10.16 Use of Options:

P530 L18640 (SO_RCVTIMEO):
If a receive operation has blocked for this much time without receiving additional data, it shall return with a partial count or errno shall be set to [EAGAIN] or [EWOULDBLOCK] if no data were received.

P531 L18665 (SO_SNDTIMEO):
If a send operation has blocked for this much time, it shall return with a partial count or errno set to [EAGAIN] or [EWOULDBLOCK] if no data were sent.


We could either repeat this detail on each affected function page or just add a reference to 2.10.16.
(0005149)
Konrad_Schwarz (reporter)
2020-12-03 10:48

My apologies; I think I was a bit tired yesterday.

I think the suggested reference would be fine.
(0005150)
shware_systems (reporter)
2020-12-03 11:25

I'm more partial to requiring EAGAIN, not either, reserving EWOULDBLOCK for discovered conditions unrelated to timing such as hardware power failure on other end, if these are 2 different values. If they are the same value this would be a case for requiring them to be different.
(0005151)
kre (reporter)
2020-12-03 13:59

Re Note: 0005150

XBD 14 <errno.h> says:

    [EAGAIN] Resource unavailable, try again (may be the same value as
          [EWOULDBLOCK]).

    [EWOULDBLOCK] Operation would block (may be the same value as [EAGAIN]).

In an I/O operation they mean the same thing, the two are very often the
same errno number (which is why the standard says they may be).

Apart from that (which I suppose could be undone, at the expense of breaking
many systems, as changing these values totally destroys binary compat for
the system) "reserving EWOULDBLOCK for discovered conditions unrelated to
timing such as hardware power failure on other end" is definitely not
EWOULDBLOCK - that's EIO.

The only argument against EAGAIN/EWOULDBLOCK here (and it is a weak one) is
that those generally occur immediately, rather than after a timeout period.
ETIMEDOUT (if it had its description changed from "connection timed out" to
"operation timed out" would probably fit a little better for an operation which
tries for a while, then eventually gives up.

But what really matters is not what anyone believes makes sense, but what
the actual implementations return.
(0005159)
shware_systems (reporter)
2020-12-04 18:02

I would expect EIO to be about the system calling the interface, not about conditions on the other end of a connection. This is because there are codes like EAGAIN that are explicitly about the other end of a connection. Maybe some implementations don't differentiate and just use EIO as a blanket report code, given the terseness of "I/O error" as its definition in <errno.h>; maybe some have EAGAIN and EWOULDBLOCK as the same value, and use that where some other implementation might use EIO, but other systems may have 3 values. It is a definite portability issue on these systems if some return EAGAIN, and others EWOULDBLOCK; it forces application code to test for both constants, bloating both code and exec time, and does not give an application sufficient info about whether to retry or abort the attempt.

There's not a single one for indicating a timeout occurred but should complete eventually (nothing broke, latency is just higher than was expected), and a different one that says something happened where it can't tell if the operation might complete (something did break, but it wasn't corrected on other end before the timeout expired), and even a third for something broke on our end and any retry can't succeed until that's fixed.
(0005281)
geoffclare (manager)
2021-03-18 15:23
edited on: 2021-03-18 15:24

On page 1793, libes 58071-58074 section recv(), change:
    
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recv( ) shall block until a message arrives.

to:
    
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recv( ) shall block until a message arrives or a timeout occurs (see SO_RCVTIMEO in [xref to section 2.10.16]).


On page 1794 line 58081 section recv() ERRORS, append:
See also SO_RCVTIMEO in [xref to section 2.10.16].


On page 1794 at line 58111 add setsockopt() to the "SEE ALSO" list.

On page 1797 lines 58170-58173 section recvfrom(), change:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvfrom( ) shall block until a message arrives.

to:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvfrom( ) shall block until a message arrives or a timeout occurs (see SO_RCVTIMEO in [xref to section 2.10.16]).


On page 1797 line 58185 section recvfrom() ERRORS, append:
See also SO_RCVTIMEO in [xref to section 2.10.16].


On page 1798 at line 58208 add setsockopt() to the "SEE ALSO" list.

On page 1799 lines 58251-58252 section recvmsg(), change:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvmsg( ) shall block until a message arrives.

to:
If no messages are available at the socket and O_NONBLOCK is not set on the socket’s file descriptor, recvmsg( ) shall block until a message arrives or a timeout occurs (see SO_RCVTIMEO in [xref to section 2.10.16]).


On page 1800 line 58284 section recvmsg() ERRORS, append:
See also SO_RCVTIMEO in [xref to section 2.10.16].


On page 1801 at line 58310 add setsockopt() to the "SEE ALSO" list.

On page 1877 line 60823-60825 section send(), change:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, send( ) shall block until space is available.

to:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, send( ) shall block until space is available or a timeout occurs (see SO_SNDTIMEO in [xref to section 2.10.16]).


On page 1877 line 60837 section send() ERRORS, append:
See also SO_SNDTIMEO in [xref to section 2.10.16].



On page 1881 lines 60918-60920 section sendmsg(), change:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, sendmsg( ) shall block until space is available.

to:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, sendmsg( ) shall block until space is available or a timeout occurs (see SO_SNDTIMEO in [xref to section 2.10.16]).


On page 1881 line 60934 section sendmsg() ERRORS, append:
See also SO_SNDTIMEO in [xref to section 2.10.16].


On page 1884 line 61051-61054 section sendto(), change:
If space is not available at the sending socket to hold the message to be transmitted and the socket file descriptor does not have O_NONBLOCK set, sendto( ) shall block until space is available.

to:
If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, sendto( ) shall block until space is available or a timeout occurs (see SO_SNDTIMEO in [xref to section 2.10.16]).


On page 1885 line 61066 section sendto() ERRORS, append:
See also SO_SNDTIMEO in [xref to section 2.10.16].



- Issue History
Date Modified Username Field Change
2020-12-02 16:57 Konrad_Schwarz New Issue
2020-12-02 16:57 Konrad_Schwarz Name => Konrad Schwarz
2020-12-02 16:57 Konrad_Schwarz Organization => Siemens AG
2020-12-02 16:57 Konrad_Schwarz User Reference => recvfrom timeout
2020-12-02 16:57 Konrad_Schwarz Section => recvfrom
2020-12-02 16:57 Konrad_Schwarz Page Number => 1
2020-12-02 16:57 Konrad_Schwarz Line Number => 1
2020-12-03 10:39 geoffclare Note Added: 0005148
2020-12-03 10:48 Konrad_Schwarz Note Added: 0005149
2020-12-03 11:25 shware_systems Note Added: 0005150
2020-12-03 13:59 kre Note Added: 0005151
2020-12-04 18:02 shware_systems Note Added: 0005159
2020-12-04 22:49 kre Note Added: 0005160
2020-12-04 23:12 kre Note Deleted: 0005160
2021-03-18 15:23 geoffclare Note Added: 0005281
2021-03-18 15:24 geoffclare Note Edited: 0005281
2021-03-18 15:25 geoffclare Interp Status => ---
2021-03-18 15:25 geoffclare Final Accepted Text => Note: 0005281
2021-03-18 15:25 geoffclare Status New => Resolved
2021-03-18 15:25 geoffclare Resolution Open => Accepted As Marked
2021-03-18 15:25 geoffclare Tag Attached: tc3-2008
2021-04-01 09:34 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker