On 15 June 2015 at 22:40, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>> 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.
>
> Most users don't actually expect OOB data. It's generally a bad idea
> to use it, since there are subtle difference between OSes, it is
> probably unwise for people to use this feature.
Sometimes you need it; invariably, if the OS offers it, someone will
come to need it.
e.g. this was recently fast tracked, as someone needed to poll the
sysfs on linux (which requires POLLPRI)
However (as a good cross platform library should), we're trying to add
baseline support for POLLPRI across all our targets.
>> 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 :)
>
> Well, given
>
> https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html
>
> I'd say, no. In fact, that article suggests this interface is no
> longer supported in OS X either.
I do recall that bug, I'm not sure what the fix the distributed ended up being.
> The article indicates that DagonFlyBSD has EVFILT_EXCEPT to signal OOB
> data. That would probably be a better choice. But as I said, the OOB
> data mechanism is an obscure feature and I'm not convinced that this
> is worth spending time on.
Ah ha! EVFILT_EXCEPT seems a much nicer solution to the problem.
Would OpenBSD consider adding support for it?
(as I mentioned above, I don't care *how* it's done, just that the
general facility is available via kqueue)
Daurn.
