On 20/10/2015 16:30, Eric Dumazet wrote:
A close() does _not_ wakeup an accept() or a poll() (this is exactly the
same problem), or any blocking system call using the same 'file'
Not waking up the accept() is one thing, allowing the accept() to
successfully complete some indeterminate time after the socket has been
closed is something else entirely. You shouldn't have to call shutdown()
to terminate an accept() on a socket, close() should suffice. Yes, if
you want to use the shutdown() 'feature' to kick the accept() thread out
of the call to accept() without closing the FD and you don't care about
cross-platform compatibility then you can call shutdown() followed by
close(). However that's only ever required on Linux as far as I can
tell, and even on Linux applications that deal with the thread race by
other means shouldn't be forced to use shutdown() when just close()
would suffice.
The problem with poll() is that it returns immediately when passed a FD
that is in the listening state. rather than waiting until there's an
incoming connection to handle. As I said, that means you can't use
poll() to multiplex between read/write/accept sockets.
close() man page states :
NOTES
It is probably unwise to close file descriptors while they may be in
use by system calls in other threads in the same process. Since a
file descriptor may be reused, there are some obscure race conditions
that may cause unintended side effects.
You are in this grey zone.
No, the race issue with file descriptor reuse and the close() behaviour
are not the same thing. The manpage comment is correct, but not relevant.
--
Alan Burlison
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
