On 20/10/2015 14:19, Eric Dumazet wrote:
That may be how Linux implements accept(), but I don't see anything
about refcounting in the POSIX spec for accept().
That's an internal implementation detail. POSIX does not document linux
kernel overall design and specific tricks.
No, neither does it document Solaris kernel design, or *BSD design, or
Windows design. It does however specify what the externally observable
behaviour has to be in order to be POSIX compliant.
linux is GPL, while Solaris is proprietary code. There is quite a
difference, and we do not want to copy Solaris behavior. We want our own
way, practical, and good enough.
I don't see what the licensing terms of particular implementations have
to do with POSIX, indeed as far as I can tell POSIX says nothing at all
about the subject. It's therefore not pertinent to this discussion.
I'm not expecting Linux to copy every Solaris behaviour, if I was I
might for example be suggesting that Linux dropped support for the
SO_RCVTIMEO and SO_SNDTIMEO setsockopt() options on AF_UNIX sockets,
because Solaris doesn't currently implement those options. That would
clearly be a ridiculous stance for me to take, what I've actually done
is logged a bug against Solaris because it's clearly something we need
to fix.
What I do think is reasonable is that if Linux claims POSIX conformance
then it either conforms or documents the variant behaviour and as I've
said I don't believe is does conform in the case of shutdown().
If POSIX makes sense we try to be compliant. If not, we do not.
That's one possible design option. However in this case the Linux
manpage claims the Linux behaviour is POSIX compliant and as far as I
can tell it isn't. As I've already said several times, I agree there's
probably not much that can be done about it without causing breakage,
which is why I suggested simply documenting the behaviour may be the
best option.
And I still haven't seen any reasoning behind the Linux close() and
poll() behaviour on sockets that are in the listen state.
If you are interested, take a look at fs/* code, and try to implement
your proposal and keep good performance.
You might find a clever way, without infringing prior art. We did not
yet.
I might, but contractually I can't, unfortunately.
--
Alan Burlison
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
