Unix domain datagram based messaging

[Jeremy Allison]

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).