Re: [Libevent-users] Ticket #70 - Support for epoll's EPOLLRDHUP

[Diego Giagio <diego@xxxxxxxxxx>]

Hi Nick, thanks for your comments.

> A key concern here is getting the API right so that code written to be
> aware of EV_EOF will not break on select() or poll() backends.

Agreed. I'm paying attention to that.

> One way to try to get it right would be to look at the "enum
> event_method_feature" logic for event backends. A backend can
> advertise one or more optional features, and "EV_FEATURE_EARLY_EOF"
> could be one of them.
>
> (I don't want to call the feature simply "EV_FEATURE_EOF", because the
> issue isn't "EOF detection" but rather "detection of EOF before
> reading all the data".)

Agreed. I also liked the EV_FEATURE_EARLY_EOF flag name.

> As for how to implement it: Here's a very simple way, though I don't
> know whether it would be acceptable.  I'd suggest treating EV_EOF as a
> subflag of EV_READ.  In other words, you couldn't make an event with
> EV_EOF unless it also has EV_READ. When listening for EPOLLIN in the
> backend, you could also listen for EPOLLRDHUP unconditionally, and
> report EPOLLRDHUP as EV_READ|EV_EOF.

I was thinking on exactly the same solution, except for the 
"event_method_feature" enum that I missed. This solution is really 
simple and backwards compatible with other backends. I would opt for that.

> A slightly trickier way would be to make EV_EOF a full-fledged flag of
> its own.  This would take a lot more work in and around evmap.c, and
> would have a higher risk of weird bugs.

I liked the first option better.

> Whatever option you pick, it would be critical to make sure that you
> can actually document and use it in a backend-neutral way.  That is,
> it needs to be possible to explain what EV_EOF means in a way that
> lets people write correct code that works just fine no matter whether
> the backend is epoll or select.

Yes, of course. By treating EV_EOF as a subflag of EV_READ I believe 
that even old code that doesn't know about EV_EOF will work correctly.

> I hope this helps!  If you've got any more ideas or questions, just ask.
>
> One idea that I support 110% is to solicit feedback on the API patch
> before writing any implementation code.  That way, if the API turns
> out to be wrong, there isn't so much throw away work in the code.

Thanks for your comments. I would opt for the first option since it's 
simpler and backwards compatible with old code.

I'm ready to implement this for epoll and kqueue afterwards. What do you 
think?

--
Diego Giagio
diego@xxxxxxxxxx
diego@xxxxxxxxxxx
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.