ev.c kqueue/freebsd

Marc Lehmann schmorp at schmorp.de
Fri Oct 11 09:47:57 CEST 2013

On Fri, Oct 11, 2013 at 09:00:22AM +0200, Richard Kojedzinszky <krichy at cflinux.hu> wrote:
> Sorry for duplicating the mail, I did not know if the mailing list
> works. Are there any test cases where the kqueue failed for you?

Not really - when I found problems, I reported them/gave up.

> they could me investigated deeply. And probably you know, that the
> freebsd folks who maintain the ports tree, enabled kqueue as
> recommended for the freebsd build

I didn't know, but that is likely out of proudness - I don't think they
test this regularly with anything but sockets and pipes (in fact, before
libev, only squid and very few other program used it, and they only used
sockets and pipes).

And yes, since most programs only do use kqueue for sockets and pipes,
this is often not detected until it fails.

> kqueue as well. That time I did not know that it should have been
> disabled by default.

Well, it still isn't disabled by default.

> And I am courious about that the port maintainer even contacted you
> about that modification.

Probably not, but it's rare that port maintainers actually contact with me
changes. And that's fine, as long as they deal with any problems :)

> If you have time, please could you give me some deeper explanation,
> examples, or failing test cases where kqueue seems to behave bad?

I didn't do a comprehensive test program - as far as I remember, I tried
out files, ttys and a few other devices (/dev/null etc)., and found only
sockets working. And this later turned out to be the case, due to the
fragile design of kqueue in the kernel: every driver has to implement
support for select and kqueue separately, which of course makes it likely
that the kqueue support will not behave correctly (at least that's what
I was told). Linux's epoll for example uses the same mechanism for
poll/select/epoll, so if it fails for epoll, it also fails for select and
poll (which usually gets detected much faster, as they are more commonly

> I am just in the case where I will use many file descriptors, and as
> after a select() we must check the fdset I think that could be worse
> in performance than a kqueue() or as an epoll() in linux.

epoll performance varies widely depending on usage patterns, and I think
epoll and kqueue are not easy to compare w.r.t. performance.

The workaround that I mentioned (use kqueue for sockets andselect or
poll for the rest) should work even in the presence of most kqueue bugs,
though, and using kqueue for sockets usually is all you need. This will
add only a a small constant overhead per loop iteration, and works

Here is the example as lifted from the libev documentation, which should
do exactly that:


For apps that only do sockets, you can just force kqueue usage in a custom
loop and use that one:

   struct ev_loop *loop = ev_loop_new (ev_recommended_backends () | EVBACKEND_KQUEUE);

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list