Subj : Re: close while read-ing To : comp.programming.threads From : Sergei Organov Date : Mon May 30 2005 03:54 pm "David Schwartz" writes: > "Sergei Organov" wrote in message > news:d76srm$k9q$1@n6.co.ru... > > > Thanks, David, I'm aware of this man page. But unfortunately it says > > nothing about unblocking of thread(s) being blocked in read(), write(), > > etc. In particular, it says: "The shutdown() function disables > > *subsequent* send and/or receive operations on a socket" but doesn't > > specify what happens to currently active send/receive blocking calls. > > > > I did try to look for the info in other man pages, such as recv() and > > send(), as well to no avail. Do you have any reference that does specify > > that waiting thread(s) are unblocked by the shutdown()? > > You are thinking about this in an odd way. 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. 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. > 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. 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. > 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." 2. return -1 and set errno to ECONNRESET: "A connection was forcibly closed by a peer." 3. return -1 and set errno to ENOTCONN: "A receive is attempted on a connection-mode socket that is not connected." What do you think the correct return value/error should be? Is the exact behavior indeed specified somewhere? -- Sergei. .