Re: checking for a closed socket

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Feb 02, 2021 at 07:39:39PM +0000, Roy Marples wrote:
> On 02/02/2021 18:20, Manuel Bouyer wrote:
> > Hello,
> > 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) ?
> > 
> > Is there a way to check if a connection has been closed without a read() ?
> 
> Oddly enough I was looking at this in poll myself recently.
> As it turns out, if the socket has a remote end (which sockets do) then the
> EOF or hangup needs to be read via POLLIN.
> If thre is no remote end (like say a file descriptor) then you get POLLHUP.
> 
> This is common with other OS's and select(2).
> The rationale is that the peer closing the socket (ie shutdown()) need is
> sent on the wire and is thus a read(), whereas the local file desciptor is
> an event.
> 
> So short answer - no. You need to read() and get the error that way.

I didn't mention it specifically, but the socket used by Xen is a
Unix (connected) socket. but I guess it's no different from network sockets.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--