|Anonymous | Login||2021-01-16 05:16 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001429||[1003.1(2016/18)/Issue7+TC2] System Interfaces||Objection||Omission||2020-12-02 16:57||2020-12-04 22:49|
|User Reference||recvfrom timeout|
|Final Accepted Text|
|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.|
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||No tags attached.|
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.
My apologies; I think I was a bit tired yesterday.
I think the suggested reference would be fine.
|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.|
Re Note: 0005150
XBD 14 <errno.h> says:
[EAGAIN] Resource unavailable, try again (may be the same value as
[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.
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.
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|