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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Wed, Dec 25, 2013 at 3:55 PM, Diego Giagio <diego@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.