Anonymous | Login | 2024-12-04 07:00 UTC |
Main | My View | View Issues | Change Log | Docs |
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 | 2024-06-11 09:08 | ||
Reporter | Konrad_Schwarz | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
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 | |||||||
|
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 |
2024-06-11 09:08 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |