[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: epoll et al, libevent

Kurt D. Zeilenga wrote:

Spending the rest of this week integrating epoll support, and it seems libevent may
be a portable way to get a lot of functionality all at once. Thoughts?

Likely a good choice, Provos's stuff is usually pretty good.
And its under a BSD license, and there is FreeBSD port.
Kegel's C10K problem page <http://www.kegel.com/c10k.html>
provides lots of good info in this area.

My only concern is that it seems to libevent is just a simple
abstraction layer, but manages directly the event loop. However,
given that our event loop sucks, that it likely a plus to move
to libevent.

I'm considering how we should integrate this support. Unfortunately it looks like we have to merge a private copy of libevent into our source tree. The libevent signal handler uses our approach of a socketpair for flagging the receipt of signals, so we should convert that to use lutil_pair among other things. All of the code needs a once-over; the select support should be integrated with our FD_SETSIZE fix, the Windows support is simply wrong, and will not handle a timeout value correctly while polling multiple descriptors, various other bits rely on things we take care of in our include/ac files so it would be cleaner if those parts were adapted and merged.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support