[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56276DA2.8010905@oracle.com>
Date: Wed, 21 Oct 2015 11:49:06 +0100
From: Alan Burlison <Alan.Burlison@...cle.com>
To: David Laight <David.Laight@...LAB.COM>,
Eric Dumazet <eric.dumazet@...il.com>
CC: Stephen Hemminger <stephen@...workplumber.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
for sockets in accept(3)
On 21/10/2015 11:25, David Laight wrote:
>> 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.
>
> That seems to work for me...
In my test case I was setting all the available event bits in
pollfd.events to see what came back. With poll() on a listen() socket
you get an immediate return with bits set in revents indicating the
socket is available for output, which of course it isn't. Indeed an
attempt to write to it fails. If you remove the output event bits in
pollfd.events then the poll() waits as expected until there's an
incoming connection on the socket.
I suppose one answer is "Well, don't do that then" but returning an
output indication on a socket that's in listen() seems rather odd.
With POLLOUT|POLLWRNORM|POLLWRBAND:
main: polling #1
[returns immediately]
main: poll #1: Success
poll fd: 0 revents: POLLOUT POLLWRBAND
main: write #1: Transport endpoint is not connected
Without POLLOUT|POLLWRNORM|POLLWRBAND:
main: polling #1
[waits for connection]
main: poll #1: Success
poll fd: 0 revents: POLLIN POLLRDNORM
--
Alan Burlison
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists