kqueue and libev

[James Mansion]

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.

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  :)