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