Austin Group Defect Tracker

Aardvark Mark IV

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 2020-12-04 22:49
Reporter Konrad_Schwarz View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Konrad Schwarz
Organization Siemens AG
User Reference recvfrom timeout
Section recvfrom
Page Number 1
Line Number 1
Interp Status ---
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.
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 No tags attached.
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.

- 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

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