|Just another Perl shrine
(tye)Re: shutdown vs. close on INET socketsby tye (Sage)
|on Aug 28, 2001 at 00:41 UTC
shutdown(0) is like close on a pipe that you are reading from -- it tells the other side that you will no longer be reading (which will change how select behaves, for example). shutdown(1) is like close on a pipe that you are writing to -- it sends an end-of-file to the reader on the other side. shutdown(2) says both of these things, but doesn't close the handle.
The reason for shutdown(0) and shutdown(1) is easy to see because a socket is two-way and you couldn't use close to send an end-of-file but still continue to read from the socket.
"perldoc -f shutdown" says that shutdown is "a more insistent form of close because it also disables the file descriptor in any forked copies in other processes". It is saying that just closeing the socket doesn't prevent any forked processes that also have the same socket open from deciding to read or write data. But it doesn't free any file handles or file descriptors, in any process, including the current one.
I had always assumed that the last close on a socket also did a shutdown(2). However, it now appears that some TCP/IP stacks don't do this (I consider this a bug and I'm rather surprised by it, but it is the simplest explanation I've found for the very high number of incoming web connections that we see that must time out because they never appear to close). So, a good network citizen will shutdown(2) before they close (if the close is meant to end communication rather than just turn communication responsibilities over the some other process).- tye (but my friends call me "Tye")