ev.c kqueue/freebsd

[Richard Kojedzinszky]

Dear Marc,

Thanks for your reply, I will do some research on this strange design of 
kqueue in freebsd. And thats strange for me that netbsd has a correct 
implementation, as all are bsd, but could that code could be totally 
different?

Thanks,

Kojedzinszky Richard

On Fri, 11 Oct 2013, Marc Lehmann wrote:

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