kqueue and libev

[Kip Macy]

On Dec 17, 2007 1:25 PM, James Mansion <james at mansionfamily.plus.com> wrote:
> Kip Macy wrote:
> >> he's just plain misinforme
> > Until we know what he is referring to we can't actually say that.
> >  -Kip
> >
>
> OK he said I could post from our private email so here goes.  There were
> bits in and around relating to the
> Solaris /dev/poll support (and the mechanism's limitations) which I've
> elided.
>
> I think the most telling thing is probably that drivers need to provide
> support and that a single mechanism
> in the driver doesn't support select and poll at the same time - which I
> guess lines up with the reported failure
> with USB serial.
>
> Does kqueue work with USB for example?  How about an AIO request to read
> from a USB endpoint?
>
> It may well just be a case of 'fessing up to system limitations.
>
> James
>
> ============================================================================
>
> Compile and install rxvt-unicode on freebsd and run it with:
>
>    urxvt               # works, uses select (or maybe poll)
>    LIBEV_FLAGS=8 urxvt # acts weird, uses kqueue
>
>    (note: only works when urxvt isn't set[gu]id)
>
> The typical symptoms are either delayed notificatrions, no notifications at
> all or _continuous_ notifications and read failing with EAGAIN. Here is a
> ktrace showing the latter: http://ue.tst.eu/45eb8a3c3e812933cbe3172af2ee4a6c.txt
>
> kqueue works well with sockets (or with about anything on netbsd), but
> fails on more exotic types such as ptys. (I test on Freebsd 6.2 RELEASE,
> but got reports about problems with earlier and later versions, too,
> as well as on openbsd (which I didn't verify) and on darwin (which is
> completely broken)).
>
>
> > You normally don't get useful writeable/readable state for files,
>
>
> No, I only want the same readyness notifications as with select or poll,
> as is documented in the manpage. (even on platforms where kqueue works
> this requires some heuristics and workarounds with kqueue due to design
> limitations (for example problems with close() or fork() that force
> constant rearming), but thats common in interfaces like kqueue, and by now
> well understood and handled by libev).
>
>
> > Actually, until recently it was broken on pipes. We've never received
> > any PRs to that effect so there is no way of knowing. You'll have
> > better luck asking the author himself.

To be more precise, this only manifested itself in erlang.

>
> Well, one should better document the types with which it works (which on
> freebsd apparently includes sockets and nothing else). I also think one
> should rethink the internal design if every driver needs its own kqueue
> support, as that will always force kqueue into a second-class citizen not
> suitable as replacement for select, as it's unreasonable to expect kqueue
> to just work when its so little used and requires such a high maintainance
> (linux' epoll for example works fine with everything because it doesn't
> require drivers to support epoll specifically, so it is unlikely that
> epoll fails when select would work for example, which is the case on
> freebsd and darwin).
>
> The fact that it works fine on everything I threw at it on netbsd is
> probably not the result of better design, but more better maintainance, so
> I wouldn't be surprised if some future version of netbsd failed in similar
> ways (OTOH, in the past, netbsd consistently was the less buggy platform
> regardless of topic, wether it was threads, ptys or kqueue, so I might get
> quite disappointed if that happened  :)

Interesting, that has been completely counter to my experience.
However, I rely on a completely different set of subsystems.

Do you have a set of regression tests for libev? It sounds like they
would worth having to regression test kqueue.

Thanks for your feedback.

 -Kip