On 14 June 2015 at 14:51, Philip Guenther <guent...@gmail.com> wrote: > On Wed, Jun 10, 2015 at 10:21 PM, Daurnimator <q...@daurnimator.com> wrote: >> I'm working on adding support for "high priority" events to a user space >> event library. >> Conceptually, I need the equivalent of poll() with POLLPRI, but via kqueue. > > POLLPRI only works for STREAMS. What sort of fd are you using this > on? What does it *mean*?
Whatever it would mean to use POLLPRI with poll(). Or a slightly looser criteria: whatever the equivalent to the 3rd set to select() means. ==> On OpenBSD, this is equivalent to POLLPRI: http://fxr.watson.org/fxr/source/kern/sys_generic.c?v=OPENBSD#L744 >> FreeBSD and Apple OSX provide this via the 'EV_OOBAND' flag to EV_SET. > > Uh, I just checked against FreeBSD subversion I don't see an EV_OOBAND > in their kqueue(2) manpage or <sys/event.h>. What version did you see > this in? Sorry, I was confused on this point; I actually only saw it in the OSX sources: On OSX, poll() with POLLPRI is actually implemented **using** kqueue with EV_OOBAND. See: http://fxr.watson.org/fxr/source/bsd/kern/sys_generic.c?v=xnu-1699.24.8#L149 >> Is there a way to wait for "high priority" events with kqueue on OpenBSD? > > Lacking a definition for "high priority", no. > > >> I had a read through various kernel sources, but didn't manage to find >> anything. >> Could OpenBSD add support for the EV_OOBAND flag? > > What Problem Are You Trying To Solve? I'm using this inside an event handling library/framework. It uses a kqueue rather than poll() or select() under the hood. The users of our API expect that they'd get the same behaviour as if they used poll directly themselves. >> Who is responsible for these sorts of things? > > Whomever is convinced it's worthwhile. Lacking a definition, it > certainly can't be. > > > Philip Guenther The issue is one of feature parity. On posix-y systems, there are multiple ways to wait for an event on a file descriptor. - select(), which takes a 'readable' set (equivalent to POLLIN), a 'writable' set (equivalent to POLLOUT), and a 'error' set (POLLPRI + some others depending on OS) - poll(), which takes POLL{IN,RDNORM, RDBAND, PRI, OUT, WRNORM, WRBAND} - Linux only: epoll(), which takes the same flags as poll() - Solaris only: port with PORT_SOURCE_FD, which takes the same flags as poll() - BSDs: kqueue: which has EVFILT_READ (with default flags is equivalent to POLLIN) and EVFILT_WRITE (equivalent to POLLOUT) Any given single threaded program generally has to pick one of the above, and use it throughout. The platform specific options (epoll, ports, kqueue) are generally more performant. The issue I'm trying to solve is: if a program needs to poll for priority events (i.e. POLLPRI) on OpenBSD, they have to use select() or poll(); it takes the kqueue option off the table. I'd like to fix this. My suggested fix was to add the same API as OSX; i.e. EV_OOBAND flag, which causes kqueue's EVFILT_READ to act like it was given POLLPRI instead of just POLLIN. But anything else that adds the ability would be fine too :)
