On Wed, Dec 25, 2013 at 3:55 PM, Diego Giagio <di...@giagio.com> wrote: [...] >> 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?
I like the design sketch above; I'd personally recommend starting out by writing the patch to include/event2/event.h for API/documentation review, and then working on the implementation stuff and the unit tests. (I'm calling it "API/documentation review" since writing the documentation first helps make sure that the API is actually good. Sometimes, my good-looking APIs turn out to be completely ugly when I start having to explain how they work.) Another thing to consider: whether anybody will someday want to watch for EOF without watching for READ. It's conceivable, and it's something that some backends will support while others cannot. I don't feel too strongly about whether libevent needs to support this EOF-without-READ option immediately, but if we don't, we should probably make sure that our API can be updated to support it later in some clean way. peace, -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
