On Fri, Oct 11, 2013 at 09:00:22AM +0200, Richard Kojedzinszky <kri...@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 used). > 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 portably. Here is the example as lifted from the libev documentation, which should do exactly that: http://ue.tst.eu/f9928a3c2faee556ee1ff413455dd743.txt 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 --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
