search

python-trio / trio

Trio – a friendly Python library for async concurrency and I/O
https://trio.readthedocs.io
Other
6.19k stars 341 forks source link

In epoll IOManager make it possible to wait on POLLPRI #61

Closed njsmith closed 6 years ago

njsmith commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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

njsmith commented 5 years ago

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.