In epoll IOManager make it possible to wait on POLLPRI

[njsmith]

Useful for e.g. GPIO support: https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

EPOLLWAKEUP might be interesting too, but is pretty exotic and a little more subtle (unlike our other events, removing an EPOLLWAKEUP from the set is actually semantically meaningful).

[njsmith]

I'm not sure if this is actually useful – e.g. the GPIO documentation linked above says "THIS ABI IS DEPRECATED ... NEW USERSPACE CONSUMERS ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI." Going to close this until the use cases are clearer.

If we do find a reason to do this, I think it should be as a low-level Linux-specific API, similar to the low-level kqueue API (#578). There's just no consistency across systems about what counts as "priority" or "exceptional" data, or how it's handled – for example, kqueue doesn't even have a (portable) way to do POLLPRI, and then there was that time that Apple tried to add support for urgent-data...

[smurfix]

No problem, I've written trio-gpio which wraps libgpiod and does exactly that.

[njsmith]

Noting for the record, since I was looking into OOB data handling for sockets, and might some day want to find this info again:

Using the BSD socket "OOB" APIs to handle TCP "urgent data" is a reasonably well-defined and portable thing. It's almost completely useless – literally the only use case I know if is to give telnet slightly better flow control when running over an unencrypted TCP connection – so I don't know that we should care. But if we did decide to care, then we would need a way to wait for "OOB" data. On Linux you can get notifications through EPOLLPRI, on Windows you can use AFD_POLL_RECEIVE_EXPEDITED, and on macOS you can use EVFILT_EXCEPT + NOTE_OOB. (This is a macOS extension though – on most BSDs there's no way to use kqueue to wait for OOB data at all. Which says something about how useless it is.)

We'd also need to think a bit about how to expose the concept: EPOLLPRI covers a few things besides OOB data (like the legacy GPIO use case that originally motivated this issue), while AFD_POLL_RECEIVE_EXPEDITED and EVFILT_EXCEPT+NOTE_OOB are very specific to OOB data.