I think shutdown(sock, SHU_RD) is mainly to let the sender generate an SIGPIPE signal in case it has sent data on a closed direction of a connection. But I think this is only for completeness. Almost always you’d use close(sock). At least I have not found a usecase when I’d want to shutdown the read-end but continue sending on write-end.
> On Feb 4, 2017, at 8:39 PM, Skip Tavakkolian <[email protected]> > wrote: > > yes, i'm still trying to find a real situation where this would be critical. > i asked go-nuts list for production examples at the same time as the start of > this thread. no answers yet. > > On Sat, Feb 4, 2017 at 3:31 AM Charles Forsyth <[email protected] > <mailto:[email protected]>> wrote: > it's also funny that the rationale seems to be to pass the same conformance > test for Go that once had it added to Inferno so it would pass a Java test > but it was never otherwise used for reasons already given, so I took it out > again. > > On 4 February 2017 at 10:11, Charles Forsyth <[email protected] > <mailto:[email protected]>> wrote: > I did once have a use for this in an o/s of mine, in a sort of network pipe > to servers, but it was so variably implemented by other systems (data was > flushed, or not) I gave it up as not particularly useful in practice, except > between two known systems that did what you wanted. > > On 4 February 2017 at 09:58, Charles Forsyth <[email protected] > <mailto:[email protected]>> wrote: > > On 4 February 2017 at 01:56, Skip Tavakkolian <[email protected] > <mailto:[email protected]>> wrote: > Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and transition > to Finwait1. > > i'd make it a "read" or "write" parameter to the existing "hangup" message. > older implementations that don't accept the parameter will give an error on > the request because the current tcp.c doesn't accept a parameter > >
