> I've been debugging an issue wuth Xen, where xenstored loops at 100%
> CPU on poll(2).
> after code analysis it's looping on closed Unix socket desriptors.
> From what I understood the code expect poll(2) to return something
> different from POLLIN when the remote end of the socket is closed (it
> checks for (~(POLLOUT|POLLIN)) to it could be either POLLERR or
> POLLHUP I guess - or eventually POLLRDHUP which we don't have).
> Who is right here, linux or NetBSD (linux claims to be posix, while
> our man page doens't mention it) ?
The poll(2) manpage in 9.1, 5.2, and 1.4T has a section
COMPATIBILITY
This implementation differs from the historical one in that a given file
descriptor may not cause poll() to return with an error. In cases where
this would have happened in the historical implementation (e.g. trying to
poll a revoke(2)ed descriptor), this implementation instead copies the
events bitmask to the revents bitmask. Attempting to perform I/O on this
descriptor will then return an error. This behaviour is believed to be
more useful.
which looks likely relevant. (The above quote is copypasted from the
1.4T manpage; the 5.2 and 9.1 versions look identical to a quick
eyeball skim, but I haven't mechanically compared them.)
> Is there a way to check if a connection has been closed without a
> read() ?
ioctl(FIONREAD), perhaps? But I suspect you mean "without an
additional syscall", in which case I suspect there is not.
I think the theory is: why does it matter? If you're not going to try
to do I/O on it, then why do you care? And if you are, then can't the
check for the peer having closed be implicit in the I/O attempt?
Is there some reason it's difficult to do it that way?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
