Bug 650985 - Interaction of close() and recv() in different threads never documented
Summary: Interaction of close() and recv() in different threads never documented
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: man-pages
Version: 5.4
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Peter Schiffer
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 857162
TreeView+ depends on / blocked
 
Reported: 2010-11-08 15:25 UTC by Casey Dahlin
Modified: 2018-11-14 16:40 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 857162 (view as bug list)
Environment:
Last Closed: 2011-11-21 07:19:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1461 0 normal SHIPPED_LIVE man-pages bug fix and enhancement update 2011-11-21 12:19:12 UTC

Description Casey Dahlin 2010-11-08 15:25:09 UTC
The customer has an application where a file descriptor is close()d while recv() is still blocking on it in another thread. In Solaris this apparently results in recv() immediately returning -1. On RHEL the recv() call blocks forever.

While there is no standards documentation that I can find that forbids RHEL's behavior, RHEL never documents its particular behavior or the rationale behind it in this case. The cusotmer would like to see such documentation.

Comment 1 Douglas Silas 2011-02-07 21:15:05 UTC
Hi Casey,

Comment 3 Casey Dahlin 2011-02-08 18:39:23 UTC
I would think the manpage recv(2).

Comment 4 Douglas Silas 2011-02-09 10:51:27 UTC
Man page fixes should be filed against the development component or, in this case, man-pages. Changing component.

Comment 5 Ivana Varekova 2011-06-09 10:44:22 UTC
Hello Casey,
from my point of view this seems like the problem in behaviour, so I prefer to change the behaviour then only to document it. Is there some special reason why you want "only" the documentation change here?
Also I'm adding to cc lczerner from the kernel team to express his opinion to this bug.

Comment 6 Siddhesh Poyarekar 2011-06-09 11:40:20 UTC
Solaris returns with a -1 with errno set to 0. This does not look like sane behaviour since it is against the common expectations of errno being set whenever read() returns -1 [1]. The closest alternative that can be thought of is to set errno as ECONNRESET.

However, in the context of read(), an ECONNRESET is explicitly for a case when the connection was closed by its peer [1], which is not the case here -- the connection is closed by the same process that is reading it. There probably is good reason to argue that access to the file descriptor must be synced between the two threads in the userspace when one is reading and the other is closing it.

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html

Comment 7 Casey Dahlin 2011-06-09 14:33:59 UTC
If the behavior changes, whatever the behavior becomes still has to be documented.

However, as I pointed out, technically the behavior is undefined as far as I can find, so it isn't technically a "problem" in behavior, just a behavior which programmers may not like. Our integrity neither binds us to change it nor forbids us from doing so.

Of course as Siddhesh points out a correct behavior other than this one might be hard to pin down.

Comment 11 RHEL Program Management 2011-09-23 00:17:41 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 19 errata-xmlrpc 2011-11-21 07:19:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1461.html


Note You need to log in before you can comment on or make changes to this bug.