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

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

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
--