[PATCH] Fix epoll backend to allow separate read/write events on one fd.

[simo]

On Wed, 2013-02-13 at 16:40 -0800, Jeremy Allison wrote:
> On Wed, Feb 13, 2013 at 09:40:53PM +0100, Stefan (metze) Metzmacher wrote:
> > 
> > I'd preferr that we don't allow more than one event handler per fd
> > in general. A socket should be only used by one logical caller
> > everything else is a bug.
> 
> Actually I've been thinking about this some more and I think
> I disagree with this assessment. It's actually a really natural
> pattern to have a separate read and write handler on the same
> file descriptor, one handling the outgoing data stream, one
> handling the incoming stream. Forcing these to be the same
> function and then separating out the required funtion within
> that handler is a lot more more clumsy.
> 
> This is perfectly illustrated by the way you use tevent
> in smbXcli_conn_create(). You explictly want separate read
> and write handlers, so you use dup() on the incoming fd to
> get around the artificial restriction that tevent is imposing
> here.
> 
> > The tdgram_context and tstream_context abstractions only need one tevent_fd.
> > 
> > At least we should allow only one TEVENT_FD_READ handler and only one
> > TEVENT_FD_WRITE handler
> > for each fd.
> 
> That is the idiom I think it's right to standardize on,
> and that's what my patch does.
> 
> > But I'd think it's better to avoid additional complexity in
> > the epoll backend,
> > which is already complex.
> 
> Yeah yeah - it's still a *lot* simpler than the poll backend,
> even *with* my multiplexing patch :-) :-).
> 
> I'd be happy if you'd review, and I'm happy to fix any
> technical issues you might have, but this does need fixing
> to allow tevent to be usable over all backends.

I tend to agree that being unable to set 2 separate callbacks is
annoying. We had to work around this tevent behavior in both sssd and
its sbus component (which wraps libdbus) and in libverto.

Other event libraries do not have this limitation. So I tend to agree
with Jeremy here on the general idea. I do not have a strong opinion on
the proposed implementation though.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>