tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: checking for a closed socket
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
--
Home |
Main Index |
Thread Index |
Old Index