Epoll::IN prevents epoll_wait an interrupt from GPIO

[keepsimple1]

polling/src/epoll.rs

Line 277 in e2129ea

Epoll::IN | Epoll::HUP | Epoll::ERR | Epoll::PRI

I'm trying to use this crate to poll GPIO interrupt in Linux (Raspberry Pi 4) via /sys/class/gpio/. But as read_flags above always include Epoll::IN, it always return a readable event for the exported gpio file (i.e. /sys/class/gpio/gpioN/value) , and hence cannot detect the interrupt.

In my testing, removing Epoll::IN (or only use Epoll::PRI) fixes this case and enables the poller detects the GPIO interrupt. However, the current poller .add() API does not accept custom read flags. I'm wondering if such issue has been considered before, and is there any plans to support custom read flags for epoll?

[notgull]

There is other precedent for making Event an opaque structure that has other platform specific info, see #112. In addition to fact that we need to make a breaking change soon (#38), I would be partial to exposing other epoll flags on the Event type.

However, we should also consider if such an abstraction should be exposed on other platforms. kqueue and poll, for instance. If so, would there be a cross-platform way of doing it?

[keepsimple1]

However, we should also consider if such an abstraction should be exposed on other platforms. kqueue and poll, for instance. If so, would there be a cross-platform way of doing it?

In poll, there is POLLPRI that is equivalent to EPOLLPRI in epoll. I'm not sure about kqueue. I was wondering, maybe Priority data is general enough to be a cross-platform thing? If yes, then maybe Event can provide an API to indicate an interest in priority data only?

[leftmostcat]

kqueue's priority mechanism seems to be platform-specific. DragonBSD and OpenBSD seem to have the EVFILT_EXCEPT filter which is combined with the NOTE_OOB filter flag, but FreeBSD does not appear to support this. macOS may support it, but I'm not certain, and it has its own mechanism via the EV_OOBAND flag on the read filter. (Note that all of this is gleaned from searches and I haven't tested any of it, so it should be taken with a grain of salt.)

[kchibisov]

However, we should also consider if such an abstraction should be exposed on other platforms. kqueue and poll, for instance. If so, would there be a cross-platform way of doing it?

Extension traits is what you can do, it's common in winit, so you should be familiar.

[notgull]

Extension traits is what you can do, it's common in winit, so you should be familiar.

When possible, I generally prefer exposing a cross-platform abstraction. Something like this would definitely be possible for event ports and Windows; unfortunately it looks like kqueue is the odd one out here.

[notgull]

As of #133 it is now possible to wait on HUP and PRI specifically.

[fogti]

well, it still isn't possible to remove IN from the flags, even with that PR merged...

[notgull]

You can do this to only select PRI events:

Event::none(key).with_pri()