Bug 650985 - Interaction of close() and recv() in different threads never documented
Interaction of close() and recv() in different threads never documented
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: man-pages (Show other bugs)
All Linux
medium Severity high
: rc
: ---
Assigned To: Peter Schiffer
BaseOS QE - Apps
: Documentation, ManPageChange
Depends On:
Blocks: 857162
  Show dependency treegraph
Reported: 2010-11-08 10:25 EST by Casey Dahlin
Modified: 2014-06-18 04:47 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 857162 (view as bug list)
Last Closed: 2011-11-21 02:19:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Casey Dahlin 2010-11-08 10:25:09 EST
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 16:15:05 EST
Hi Casey,
Comment 3 Casey Dahlin 2011-02-08 13:39:23 EST
I would think the manpage recv(2).
Comment 4 Douglas Silas 2011-02-09 05:51:27 EST
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 06:44:22 EDT
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 07:40:20 EDT
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 10:33:59 EDT
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 Product and Program Management 2011-09-22 20:17:41 EDT
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 02:19:58 EST
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.


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