Re: checking for a closed socket

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B