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

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

On 23/10/2015 17:19, Eric Dumazet wrote:

>>> The AF_UNIX poll one? No, I don't have the means to do so, and in any
>>> case that's not a POSIX issue, just a plain bug. I'm happy to log a bug
>>> if that helps.
>
> BTW, there is no kernel bug here. POSIX poll() man page says :
>
> POLLOUT
>      Normal data may be written without blocking.
>
> If you attempt to write on a listener, write() does _not_ block and
> returns -1, which seems correct behavior to me, in accordance with man
> page.

Except of course data may not be written, because an attempt to actually 
do so fails, because the socket is in the listen state, is not connected 
and therefore no attempt to write to it could ever succeed. The only bit 
of the required behaviour that the current AF_UNIX poll implementation 
actually gets right is the "without blocking" bit, and that's only the 
case because the failure is detected immediately and the write call 
returns immediately with an error.

> socket(PF_LOCAL, SOCK_STREAM, 0)        = 3
> bind(3, {sa_family=AF_LOCAL, sun_path=@""}, 110) = 0
> listen(3, 10)                           = 0
> write(3, "test", 4)                     = -1 ENOTCONN (Transport endpoint is not connected)
>
> Could you point out which part of POSIX is mandating that af_unix
> listener MUST filter out POLLOUT ?

"A file descriptor for a socket that is listening for connections shall 
indicate that it is ready for reading, once connections are available. A 
file descriptor for a socket that is connecting asynchronously shall 
indicate that it is ready for writing, once a connection has been 
established."

If POSIX had to explicitly list every possible thing that 
implementations *should not* do rather than just those that they 
*should* do then it would be even more unwieldy than it already is.

And if what you are asserting is correct, why isn't the AF_INET 
behaviour the same as the AF_UNIX behaviour?

-- 
Alan Burlison
--