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
