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

[Jeremy Allison]

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.

Cheers,

	Jeremy.