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

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

On 27/10/2015 23:17, Al Viro wrote:

> Frankly, as far as I'm concerned, the bottom line is
> 	* there are two variants of semantics in that area and there's not
> much that could be done about that.

Yes, that seems to be the case.

> 	* POSIX is vague enough for both variants to comply with it (it's
> also very badly written in the area in question).

On that aspect I disagree, the POSIX semantics seem clear to me, and are 
different to the Linux behaviour.

> 	* I don't see any way to implement something similar to Solaris
> behaviour without a huge increase of memory footprint or massive cacheline
> pingpong.  Solaris appears to go for memory footprint from hell - cacheline
> per descriptor (instead of a pointer per descriptor).

Yes, that does seem to be the case. Thanks for the detailed explanation 
you've provided as to why that's so.

> 	* the benefits of Solaris-style behaviour are not obvious - all things
> equal it would be interesting, but the things are very much not equal.  What's
> more, if your userland code is such that accept() argument could be closed by
> another thread, the caller *cannot* do anything with said argument after
> accept() returns, no matter which variant of semantics is used.

Yes, irrespective of how you terminate the accept, once it returns with 
an error it's unsafe to use the FD, with the exception of failures such 
as EAGAIN, EINTR etc. However the shutdown() behaviour of Linux is not 
POSIX compliant and allowing an accept to continue of a FD that's been 
closed doesn't seem correct either.

> 	* [Linux-specific aside] our __alloc_fd() can degrade quite badly
> with some use patterns.  The cacheline pingpong in the bitmap is probably
> inevitable, unless we accept considerably heavier memory footprint,
> but we also have a case when alloc_fd() takes O(n) and it's _not_ hard
> to trigger - close(3);open(...); will have the next open() after that
> scanning the entire in-use bitmap.  I think I see a way to improve it
> without slowing the normal case down, but I'll need to experiment a
> bit before I post patches.  Anybody with examples of real-world loads
> that make our descriptor allocator to degrade is very welcome to post
> the reproducers...

It looks like the remaining discussion is going to be about Linux 
implementation details so I'll bow out at this point. Thanks again for 
all the helpful explanation.

-- 
Alan Burlison
--