Red Hat Bugzilla – Bug 650985
Interaction of close() and recv() in different threads never documented
Last modified: 2014-06-18 04:47:24 EDT
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.
Hi Casey,
I would think the manpage recv(2).
Man page fixes should be filed against the development component or, in this case, man-pages. Changing component.
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.
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
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.
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.
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