1. read(fd, buf, size) after shutdown(fd, SHUT_RD) implementation-defined
I notice some missing specification in the documentation on shutdown():
The Linux man page and glibc info page say that shutdown(fd, SHUT_RD)
shuts off "reception" of data on the socket. Single Unix Spec says
"disables further receive operations". That sounds like it applies to the
tcp/ip session, not to the process's ability to read() if the socket
read buffer still has data when shutdown() is called. Neither the man
pages, info pages, or SuS man page say anything about what the
semantics of read() should be after shutdown(fd, SHUT_RD) is called.
The SO_LINGER option only discusses the write() direction: "close() and
shutdown() will block until all data has been written". (I wonder how
O_NONBLOCK works with that, but that's a question for another day).
An ipc tutorial from Berkeley's CSRG, issued when 4.3 bsd was the current bsd
Should a user have no use for any pending data, it may perform a
"shutdown" on the socket prior to closing it. This call is of the
where "how" is 0 if the user is no longer interested in reading
data, 1 if no more data will be sent, or 2 if no data is to be
sent or received.
This appears to simply assume that code is not going to call read()
on the socket after shutdown(fd, SHUT_RD), and so leaves the question
of how the kernel is to respond to such a read() call undefined.
(Joys of an ad-hoc spec defined by the code that first implemented it,
and whose later formalization failed to specify the semantics of subsequent
file operations on the socket fd after shutdown().)
So I would merely take the position that "results of read(fd, buf, size)
after shutdown(fd, SHUT_RD) has been called are implementation-defined"
(meaning that any given kernel will do something in that situation, but
code cannot expect how one kernel reacts to read() after
shutdown(fd, SHUT_RD) to be portable to other systems or kernel
versions without some formal standard specifying those semantics).
It seems prudent to not rely on the socket's read buffer to still be available
to the process after telling the kernel that you no longer have any
interest in reading from it. Anything the kernel does with the socket's
read buffer after shutdown(fd, SHUT_RD) is unspecified and thus valid
How quickly the kernel gets around to actually notifying the remote peer
that the socket is closed for writing is internal to the tcp/ip stack.
"Immediately" would be good, but it is not going to be seen by the reader
that called shutdown() in any case.
Mutliple reader/writer apps that share a socket should still use locks and
"open/closed for i/o flags" (that are checked once a process or thread
holds the lock) to insulate themselves from variations in
(implementation-defined) "i/o after shutdown()" behavior, imho.
"Everyone is ignorant, just about different things." Will Rogers
2. Finding .c, .cc, .cpp, .cxx and uppercase variants in one go with "find" ?
3. Adaptec 2940 doesn't support 32-bit DMA?
4. Problems compiling kernel - more details
5. Solaris 9 installed with 32 & 64 bit supports but boots in 32 bit mode
6. ati rage pro and X windows help
7. 64-bit Solaris 7: wasn't Solaris 2.6 also 32-bit?
8. New Linux Page -- Preview
9. Can't use 16-bit, 32-bit modes
10. write (socket, buf, 0) and read (socket, buf, 0)
11. How 32 bit driver can be ported to 64 bit driver?
12. 32 bits vs. 64 bits Oracle
13. 32 bit or 64 bit