Unix domain datagram based messaging

[Jeremy Allison]

On Thu, Apr 10, 2014 at 12:15:42PM -0700, Jeremy Allison wrote:
> On Thu, Apr 10, 2014 at 09:09:28PM +0200, Volker Lendecke wrote:
> > On Thu, Apr 10, 2014 at 12:02:13PM -0700, Jeremy Allison wrote:
> > > On Thu, Apr 10, 2014 at 08:46:58PM +0200, Volker Lendecke wrote:
> > > > On Thu, Apr 10, 2014 at 10:05:31AM -0700, Jeremy Allison wrote:
> > > > > In fact the only thing I can see that
> > > > > might be an issue here is how does
> > > > > unix_dgram_recv_handler() handle
> > > > > a it if we get a geniune error that
> > > > > causes recv() to return -1. Won't it
> > > > > keep getting called ? I'll do some
> > > > > more digging here..
> > > > 
> > > > Yep, that's what I thought as well. ENOMEM is one that might
> > > > hit us like the Solaris socket problem, but there retry
> > > > should not hurt and might be the right thing. The only thing
> > > > I can really imagine to happen here is that someone else
> > > > closes the socket behind our back, but then we deserve a
> > > > 100% loop, right? :-)
> > > 
> > > Errr, well - maybe :-). Can't you have
> > > the struct poll_watch->callback return
> > > an int to tevent_watch_handler(), and
> > > have it remove the fde if it comes
> > > back with -1 ? That at least would
> > > protect us from horrible CPU loops :-).
> > 
> > Question: Why would the event loop call a handler on this
> > kind of error? I can see the 100% loop in poll itself, but
> > do we call the callback if we just see POLLERR or the epoll
> > equivalent?
> 
> I thought an error would return POLLIN or POLLRDHUP ?
> 
> If it returns POLLIN we'll call the hander.
> 
> On a read fd we'll never get POLLERR, from the Linux
> man page:
> 
>               POLLERR
>                      Error condition (output only).
> 
> (I'm assuming epoll is the same).

Yeah - looks like POLLRDHUP might be Linux (or GNU_SOURCE) only :

              POLLRDHUP (since Linux 2.6.17)
                     Stream socket peer closed connection, or  shut  down  writing  half  of  connection.   The
                     _GNU_SOURCE  feature  test  macro  must  be defined (before including any header files) in
                     order to obtain this definition.

Which means a generic implementation might
return POLLIN on a read error.

And in fact looking inside our tevent_epoll backend
we have:

                if (events[i].events & (EPOLLHUP|EPOLLERR)) {
			... stuff...
			flags |= TEVENT_FD_READ;
		}

		... later...

		if (flags) {
                        fde->handler(epoll_ev->ev, fde, flags, fde->private_data);
                        break;
                }

so yeah we will call the read handler on error on
a read fd.

Just trying to make this stuff bullet-proof :-).

Jeremy.