kqueue for sockets on freebsd (non-polling)

Eric Brown yogieric.list at gmail.com
Wed Jan 9 19:20:13 CET 2008

Hi Marc,

On Jan 9, 2008, at 7:58 AM, Marc Lehmann wrote:

> On Wed, Jan 09, 2008 at 01:20:35AM -0800, Eric Brown <yogieric.list at gmail.com 
> > wrote:
>> Anyway, I read a number of concerns about libev & kqueue.
> What concerns? libev supports kqueue just fine... It is kqueue that  
> is making
> problems on most BSDs, though.

There were a few comments in the libev docs and mailing list. It  
wasn't always clear to me as to whether the concerns were about kqueue  
or about the way libev uses kqueue. Hence my question. :)

Assuming I go with libev (likely), I'm developing on leopard but my  
target is freebsd. If there's some amount of testing you need, let me  

>> Since all I care about are sockets, can I get libev to use kqueue  
>> in an
>> efficient non-polling mode? Or am I better off looking at libevent or
>> using kqueue directly?
> What do you mean with "kqueue in non-polling mode"? afaik, kqueue only
> supports a polling mode, and this is what both libevent and libev use.

I'm talking about kevent(..., const struct timespec *timeout). Since I  
don't care about signals, fork events, etc. - all I care about is  
sockets - I don't think I want a 0 timeout in the call to kevent(). I  
see ev_set_io_collect_interval and I'm guessing this is what controls  

So by polling, all I meant was use of kevent with a 0 timeout.

>> Sorry, I'm new to libev and kqueue - more used to using select()
>> directly or other higher level APIs. But libev looks really great.
> Thanks. While, of course, I think that libev has a lot of advantages  
> over
> libevent (such as a more rational API (espeically when  
> multithreading) and
> higher performance), libevent is certainly adequate to the job as  
> well.
> You should probably look at the libevent example program, and the  
> libev
> documentation (which also has examples) and choose the one that  
> appeals most
> to you.
> If you are only interested in sockets and simple timeouts, then both
> libraries have the same feature set (although understanding how  
> timeouts
> work in libevent can be difficult, it certainly was for me).
> libevent example: http://monkey.org/~provos/libevent/event-test.c
> libevent docs: http://monkey.org/~provos/libevent/doxygen/
> libev docs: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod
> If you insist on using kqueue everywhere (watch out, its buggy on  
> most os
> x releases even for sockets), then this will give you an event loop  
> using
> kqueue in libev, whenever kqueue is available:
>   #include <ev.h>
>   struct ev_loop *loop =
>      ev_loop_new (
>         ev_recommended_backends () | EVBACKEND_KQUEUE
>      );
>   assert ((loop, "libev initialisation failed"));

Thanks! I'm being told by a customer to use kqueue. At least with  
libev I can easily switch to something else if it doesn't work out.

BTW, I'm told I need to support 1000s of connections. But my suspicion  
is that reality may be in the low 100s. On a fast server, do you have  
any idea where the cross-over is between poll/select and kqueue  
performance? I see your benchmarks, but I don't think they compare  
different mechanisms.


More information about the libev mailing list