libevent and epoll

[Anatoly Vorobey]

On Thu, Sep 11, 2003 at 04:42:55PM -0400, Perrin Harkins wrote:
> > Building libevent with epoll support is trickier than rebuilding the
> > kernel... you have to mess with some headers in /usr/include/, but it's
> > fine.
> 
> I was able to build a source RPM from DAG on my 2.4 system:
> http://dag.wieers.com/packages/libevent/
> 
> I was also able to build memcached against that, but it complained at
> startup about epoll functions not being implemented.  I think that
> complaint comes from glibc.  I stopped there, so I'm not sure if it was
> falling back to select or just not functional.

Have you looked at the BUILD file in memcached's distribution?

It explains how to build libevent with epoll support, and then to build
memcached. 

If you're using a static binary of memcached built with epoll support,
you don't have to bother with libevent or anything else except epoll
support in the kernel. If you don't have that, memcached will complain
at startup, exactly as you wrote above, because the libevent it was
linked up against thinks it can use epoll syscalls, but they're 
actually not supported by the kernel. The complaints are printed by 
libevent, not glibc. It'll still go on to work with poll/select. On
the other hand, if you build libevent and link memcached against it on
a machine w/o epoll support, you'll have no warnings but this memcached
will never use epoll, even on a machine that has it in the kernel -
because libevent doesn't build its epoll support if it can't find it
on the machine at compile time.

--
avva