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?
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.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.
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support