Date: Mon, 17 Dec 2007 21:25:01 +0000 From: James Mansion <james@mansionfamily.plus.com> To: Kip Macy <kip.macy@gmail.com> Cc: freebsd-hackers@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: kqueue and libev Message-ID: <4766E92C.6020703@mansionfamily.plus.com> In-Reply-To: <b1fa29170712151407v4eca6a78hda7dd75ab9367ca7@mail.gmail.com> References: <4763A398.2040109@mansionfamily.plus.com> <47644BFE.3060003@elischer.org> <b1fa29170712151407v4eca6a78hda7dd75ab9367ca7@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4766E92C.6020703>