Subj : Re: close while read-ing
To   : comp.programming.threads
From : David Schwartz
Date : Tue May 31 2005 06:29 pm


"Sergei Organov" <osv@javad.ru> wrote in message 
news:d7hl98$k7o$1@n6.co.ru...

> Thanks a lot. Now its seem I've got your explanation (at least
> partially). Do I now understand right that shutdown() doesn't do
> anything special with respect to thread(s) waiting in recv(); instead,
> the result of shutdown() execution is a change in underlying connection
> state that is then handled as usual?

    Yes, in concept. How it's actually implemented, of course, could be that 
it does do someting special to blocked threads. But that's the way you 
should think about it -- it shuts down the connection, and then that does 
whatever it must.

> What is still unclear: is shutdown() call from another thread the right
> way to close a stuck connection in the case when the peer has silently
> disappeared? Does SO_LINGER option have anything to do with it (the
> setsockopt() man page suggests it only affects close(), not shutdown())?

    A 'shutdown' requests the orderly shutdown of a network connection. The 
connection must either shutdown or time out at that time (assuming you 
didn't just shut down the receive half of the connection, in which case the 
other half can proceed for as long as needed).

    You kind of have this backwards, which is natural because it's more 
common to use 'close' than 'shutdown'. Fundamentally, 'close' releases a 
file descriptor. If that file descriptor happens to reference a socket, and 
this is the last descriptor for that socket, then the 'close' also implies a 
full shutdown. The 'shutdown' function allows you to request a full (or 
partial) shutdown without invalidating any descriptors and even if some 
other thread/process also has a descriptor for the same socket.

    The SO_LINGER option does not come into play when you call 'shutdown'. 
When you fully shutdown a connection, it will make every attempt to flush 
buffers to the other side. You can call 'close' later and force the shutdown 
to complete and/or linger. See, for example, 
http://docs.hp.com/en/B2355-90136/ch03s05.html

    A 'shutdown' of the connection in both directions is the correct way to 
try to terminate the connection if you do not want to invalidate the socket 
descriptor or are unsure if there are other descriptors for the same socket. 
One reason you might want to do this is if you detect a timeout and another 
thread is or might be blocked using the socket (blocked on receive, or in 
select, or about to call send, or whatever).

    DS

.