kqueue and libev
kip.macy at gmail.com
Mon Dec 17 13:54:59 PST 2007
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
> 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.
> 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.
More information about the freebsd-hackers