Dear Narc,
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? You have
mentioned exotic cases, but maybe if you provide some examples, 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
(https://github.com/freebsd/freebsd-ports/blob/master/devel/libev/files/patch-ev.c).
I noticed this as I use libev on freebsd, and have seen that it uses
kqueue as well. That time I did not know that it should have been disabled
by default. Later I installed p5-AnyEvent, and p5-EV modules as well,
tried to use a little perl script. And debugging that script I noticed it
uses select(). And I've found that p5-EV has a libev copy inside it, and
not using the installed one, in which the freebsd port maintainer has not
made a similar patch enabling kqueue by default. So this incosistency made
me to ask your oppinion. And I am courious about that the port maintainer
even contacted you about that modification.
If you have time, please could you give me some deeper explanation,
examples, or failing test cases where kqueue seems to behave bad?
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.
Thanks in advance,
Kojedzinszky Richard
On Fri, 11 Oct 2013, Marc Lehmann wrote:
On Thu, Oct 10, 2013 at 11:06:02AM +0200, Richard Kojedzinszky
<kri...@cflinux.hu> wrote:
Why is kqueue disabled on freebsd?
It isn't disabled on freebsd, so I am not sure what you mean with this
question.
I looked at the code, and it says kqueue is borked on everything but
netbsd. What is exactly wrong with freebsd's kqueue?
The very unfortunate design of kqueue means that every driver needs
special support for it, and this is almost a guarantee that it won't
work. This is why libev errs on the side of correctness by default and
doesn't have it in the set of recommended backends.
When you know you only are going to use sockets (which seem to always
work), and possibly pipes (which usually work), then you can request
kqueue support and it will work. If you use more "exotic" file types
(ttys, usb, other character devices), then you are advised to check first.
A good design on freebsd would be to use a select-based default loop (so
other components just work), and for your main kqueue-supported filetype
(usually sockets) create a separate kqueue event loop and embed it into the
default loop.
That way, you get kqueue scalability for sockets without compromising
correctness.
As for the "date of this writing", there were problems with freebsd 9.0
and 8.x, so I would expect problems to be still there. And given the
fragile design of the kernel in this part, I would expect problems to come
back regularly. It's one of the few areas where epoll really was better
designed.
--
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
