[Date Prev][Date Next]
Re: epoll et al, libevent
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: Re: epoll et al, libevent
- From: Howard Chu <email@example.com>
- Date: Tue, 16 Nov 2004 22:44:23 -0800
- Cc: openldap-devel@OpenLDAP.org
- In-reply-to: <firstname.lastname@example.org>
- References: <419AA911.email@example.com> <firstname.lastname@example.org>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041101
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
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support