Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

[Alan Burlison <Alan.Burlison@oracle.com>]

On 22/10/2015 13:10, Eric Dumazet wrote:

>> Sentiments such as that really have no place in a discussion that's been
>> focussed primarily on the behaviour of interfaces, albeit with
>> digressions into the potential performance impacts. The discussion has
>> been cordial and I for one appreciate Al Viro's posts on the subject,
>> from which I've leaned a lot. Can we please keep it that way? Thanks.
>
> Certainly not.

OK, in  which case I'll make this my last on-list reply to this part of 
the thread as I think continuing it is unlikely to be productive. If you 
would like to further discuss your concerns about my motivations I'm 
happy to do so off list, along with anyone you want to cc in. Thanks.

> I am a major linux networking developper and wont accept linux is
> hijacked by guys who never contributed to it, just so it meets their
> unreasonable expectations.

Yes, I'm aware of who you are. And if my expectations were completely 
unreasonable then I'd have expected the conversation to have already 
drawn to a close by now.

> We absolutely care about performance. And I do not care you focus on
> POSIX crap.

Yes, I understand the concern about the potential performance impact and 
it's a valid concern. And I also understand that the current Linux 
behaviour of shutdown() on unconnected sockets probably can't be changed 
without causing breakage and is therefore unlikely to happen as well.

The issues I hit were in the context of application porting, where the 
APIs in question are covered by POSIX. The Linux manpages for open(), 
close(), socket(), dup2() and shutdown() all claim POSIX.1-2001 
conformance. If performance is the most important concern then it's a 
valid decision to prioritise that over POSIX conformance, you simply 
can't continue to claim that the relevant Linux APIs are fully POSIX 
conformant, so I believe at the minimum the Linux manpages need modifying.

-- 
Alan Burlison
--