ev.c kqueue/freebsd

[Richard Kojedzinszky]

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 <krichy at 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
>      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>      -=====/_/_//_/\_,_/ /_/\_\
>