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 di...@giagio.com di...@freebsd.org *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
