Re: kqueue and libev

On Dec 17, 2007 1:25 PM, James Mansion <james@xxxxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: kqueue and libev
    ... Solaris /dev/poll support which I've elided. ... Does kqueue work with USB for example? ... The typical symptoms are either delayed notificatrions, no notifications at ... The fact that it works fine on everything I threw at it on netbsd is ...
    (freebsd-hackers)
  • Re: KQueue and Threads?
    ... > couple months ago I wrote the KQueue support for Apache2/APR. ... > Thread A is in a keventwaiting for events to happen on a set of FDs. ...
    (freebsd-hackers)
  • Re: Kqueue write event position?
    ... knoteis generic and is used for all types of notifications, ... probably roll down your own replacement and call it from VN_KNOTE. ... Before I get any further with this, can anyone predict what would be the impact of monitoring a large number of files with kqueue? ...
    (freebsd-hackers)
  • Re: devd limitations / automounting removable storage
    ... >> modules can register to receive notifications when events came in. ... > Please use kqueue. ...
    (freebsd-arch)