[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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

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
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.