On 22/10/2015 05:44, Al Viro wrote:
It's been said that the current mechanisms in Linux & some BSD
variants can be subject to races
You do realize that it goes for the entire area? And the races found
in this thread are in the BSD variant that tries to do something similar
to what you guys say Solaris is doing, so I'm not sure which way does
that argument go. A high-level description with the same level of details
will be race-free in _all_ of them. The devil is in the details, of course,
and historically they had been very easy to get wrong. And extra complexity
in that area doesn't make things better.
Yes, I absolutely agree it's difficult to get it right. Modulo
undetected bugs I believe the Solaris implementation is race free, and
if it isn't I think it's fair to say we'd consider that to be a bug.
, and the behaviour exhibited
doesn't conform to POSIX, for example requiring the use of
shutdown() on unconnected sockets because close() doesn't kick off
other threads accept()ing on the same fd.
Umm... The old kernels (and even more - old userland) are not going to
disappear, so we are stuck with such uses of shutdown(2) anyway, POSIX or
no POSIX.
Yes, I understand the problem and in an earlier part of the discussion I
said that I suspected that all that could really be done was to document
the behaviour as changing it would break existing code. I still think
that's probably the only workable option.
I'd be interested to hear
if there's a better and more performant way of handling the
situation that doesn't involve doing the sort of bookkeeping Casper
described,.
So would a lot of other people.
:-)
To quote one of my colleague's favourite sayings: Performance is a
goal, correctness is a constraint.
Except that in this case "correctness" is the matter of rather obscure and
ill-documented areas in POSIX. Don't get me wrong - this semantics isn't
inherently bad, but it's nowhere near being an absolute requirement.
I don't think it's *that* obscure, when I found the original shutdown()
problem google showed up another occurrence pretty quickly -
https://lists.gnu.org/archive/html/libmicrohttpd/2011-09/msg00024.html.
If a fd is closed then allowing other uses of it to continue in other
threads seems incorrect to me, as in the dup2() scenario I posted.
--
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
