Subj : Re: close while read-ing To : comp.programming.threads From : David Schwartz Date : Mon May 30 2005 12:09 pm "Sergei Organov" wrote in message news:d7erdp$k57$1@n6.co.ru... > Odd? Suppose we need to implement the recv() and shutdown() calls in > multi-threaded environment. Suppose we've read manpages for both and > took them as interface specification. Suppose we've implemented the > calls so that shutdown() called from a thread doesn't unblock another > thread waiting in recv(). The question is: did we violate the interface > specification? I'm afraid the answer is no. No, the answer is yes. The 'recv' function cannot block forever. When the connection shuts down, the 'recv' function must unblock. > On the other hand, if we do decide to implement return from recv() on > shutdown(), we still have no exact specification of what should be > returned on exit from recv(), more on that below. Zero. The connection shut down normally while the 'recv' was blocking. >> It's not that the threads are unblocked, it's that the operation now >> returns with an error because the connection is shutdown. > Then why the man page explicitly says "disables *subsequent* send and/or > receive operations"? My guess is that the reason is just historical, -- > apparently the man page has been written before threads have been > introduced and hasn't been updated since then. It's possible that the reason is historical, but it's still a precise and correct description of what 'shutdown' does. > Alternatively, I thought that maybe there is some documentation that > I've overlooked that describes blocking syscalls behavior with respect > to asynchronous syscalls from other threads, and that's why I've asked > you for reference. Again, you are thinking about this the wrong way. A thread that is blocking in a socket operation is *always* waiting for something to happen that is asynchronous with respect to that thread. >> What must happen if the connection shuts down while a read or write is >> blocking? > That's what relevant documentation should say, not me, I believe. My > opinion is that waiting thread(s) must be unblocked though I'm not sure > what should be returned. E.g., there are three apparently somewhat > suitable recv() results described in the recv() man page, from which > only the first one has the term "shutdown", the first and second are > peer-related, and the third doesn't seem to be the right choice: > > 1. return 0: "If no messages are available to be received and the peer > has performed an orderly shutdown, recv() shall return 0." This is correct if the peer shuts the connection down in an orderly way. (Which could happen after a 'shutdown', but doesn't have to happen.) > 2. return -1 and set errno to ECONNRESET: "A connection was forcibly > closed by a peer." This is correct if the peer responds to the shutdown request by aborting the connection. This could also happen. > 3. return -1 and set errno to ENOTCONN: "A receive is attempted on a > connection-mode socket that is not connected." I don't think this can happen. > What do you think the correct return value/error should be? Is the exact > behavior indeed specified somewhere? It depends what shutdown you use and what the peer does. Normally, one would expect the peer to respond with a normal closure and get a zero. If the peer closes the connection without reading all the data, ECONNRESET is appropriate. DS .